From jira-events at lists.jboss.org  Wed Jul  1 14:46:51 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 1 Jul 2009 14:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (EJBTHREE-1860) adda check and
 don't process EJB2 metadata in Ejb3AnnotationHandler
In-Reply-To: <1456911370.1246456851425.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1504647072.1246474011716.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reopened EJBTHREE-1860:
------------------------------------



Re-opening to add the "component"

> adda check and don't process EJB2 metadata in Ejb3AnnotationHandler
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1860
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1860
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: core
>    Affects Versions: 1.1.8
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.1.9
>
>
> This is inspired by JBMETA-208. As I explained in JBMETA-208, EJB2 metadata shouldn't even get that far. But I'll add one if-statement anyway to make sure we don't run into an issue like that again.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 14:56:02 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 1 Jul 2009 14:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7013) Seam Booking
 IOException with JSF2 Beta1 on AS5
In-Reply-To: <23174748.1244831337615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1818232289.1246474562589.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert resolved JBAS-7013.
--------------------------------

    Resolution: Done


Verified fixed in nightly of Mojarra 2.0

> Seam Booking IOException with JSF2 Beta1 on AS5
> -----------------------------------------------
>
>                 Key: JBAS-7013
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7013
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>
> I drop-in replaced JSF in AS5.1 with JSF 2 Beta 1.  
> With the Seam Booking demo, I bundle the old facelets and have:
>    <context-param>
>       <param-name>javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER</param-name>
>       <param-value>true</param-value>
>     </context-param>
> I get the stack trace below.  Though it doesn't seem to affect the application, I need to figure out why this is happening.
> 13:38:34,463 ERROR [compiler] Error Loading Library: vfszip:/C:/jboss-5.1.0.GA/s
> erver/default/deploy/jbossweb.sar/jsf-libs/jsf-impl.jar/META-INF/mojarra_ext.tag
> lib.xml
> java.io.IOException: Error parsing [vfszip:/C:/jboss-5.1.0.GA/server/default/dep
> loy/jbossweb.sar/jsf-libs/jsf-impl.jar/META-INF/mojarra_ext.taglib.xml]:
>         at com.sun.facelets.compiler.TagLibraryConfig.create(TagLibraryConfig.ja
> va:410)
>         at com.sun.facelets.compiler.TagLibraryConfig.loadImplicit(TagLibraryCon
> fig.java:431)
>         at com.sun.facelets.compiler.Compiler.initialize(Compiler.java:87)
>         at com.sun.facelets.compiler.Compiler.compile(Compiler.java:104)
>         at com.sun.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFace
> letFactory.java:218)
>         at com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFacelet
> Factory.java:149)
>         at com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFacelet
> Factory.java:100)
>         at com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java
> :517)
>         at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.jav
> a:567)
>         at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWra
> pper.java:108)
>         at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.j
> ava:216)
>         at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePha
> se.java:124)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:103)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:311)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.HotDeployFilter.doFilter(HotDeployFilter.java:53)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFi
> lter.java:96)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
> alve.java:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
> alve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(Securit
> yAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValv
> e.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.proce
> ss(SecurityContextEstablishmentValve.java:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invok
> e(SecurityContextEstablishmentValve.java:70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
> ava:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
> ava:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedC
> onnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
> ve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
> a:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
> :829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
> ss(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:44
> 7)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: org.xml.sax.SAXException: Error Handling [vfszip:/C:/jboss-5.1.0.GA/s
> erver/default/deploy/jbossweb.sar/jsf-libs/jsf-impl.jar/META-INF/mojarra_ext.tag
> lib.xml at 42,29]
>         at com.sun.facelets.compiler.TagLibraryConfig$LibraryHandler.error(TagLi
> braryConfig.java:376)
>         at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)
>         at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
>         at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
>         at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
>         at org.apache.xerces.impl.dtd.XMLDTDValidator.rootElementSpecified(Unkno
> wn Source)
>         at org.apache.xerces.impl.dtd.XMLDTDValidator.handleStartElement(Unknown
>  Source)
>         at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Sourc
> e)
>         at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElemen
> t(Unknown Source)
>         at org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanR
> ootElementHook(Unknown Source)
>         at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent
> Dispatcher.dispatch(Unknown Source)
>         at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un
> known 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 Sour
> ce)
>         at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
>         at javax.xml.parsers.SAXParser.parse(SAXParser.java:198)
>         at com.sun.facelets.compiler.TagLibraryConfig.create(TagLibraryConfig.ja
> va:407)
>         ... 54 more
> Caused by: org.xml.sax.SAXParseException: Document root element "facelet-taglib"
> , must match DOCTYPE root "null".
>         at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Un
> known Source)
>         ... 73 more

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

        


From jira-events at lists.jboss.org  Wed Jul  1 14:48:51 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 1 Jul 2009 14:48:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1860) adda check and
 don't process EJB2 metadata in Ejb3AnnotationHandler
In-Reply-To: <1456911370.1246456851425.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <491705736.1246474131425.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1860.
------------------------------------

    Resolution: Done


> adda check and don't process EJB2 metadata in Ejb3AnnotationHandler
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1860
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1860
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: core
>    Affects Versions: 1.1.8
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.1.9
>
>
> This is inspired by JBMETA-208. As I explained in JBMETA-208, EJB2 metadata shouldn't even get that far. But I'll add one if-statement anyway to make sure we don't run into an issue like that again.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 14:19:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 1 Jul 2009 14:19:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6372) Add data source
 configuration files for Ingres RDBMS support
In-Reply-To: <3379588.1231456084356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1466498599.1246472391896.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBAS-6372:
----------------------------------

            Issue Type: Feature Request  (was: Patch)
     Original Estimate:     (was: 30 minutes)
    Remaining Estimate:     (was: 30 minutes)
           Component/s: JCA service
                            (was: Other)
              Assignee: Jesper Pedersen
              Priority: Minor  (was: Optional)


> Add data source configuration files for Ingres RDBMS support
> ------------------------------------------------------------
>
>                 Key: JBAS-6372
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6372
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.Beta1, JBossAS-6.0.0.Alpha1, JBossAS-Branch_4_2
>         Environment: N/A
>            Reporter: murray armfield
>            Assignee: Jesper Pedersen
>            Priority: Minor
>         Attachments: create_database.sql, create_database.sql, JBAS-ingres.tar.gz, jboss-soa-p.4.3.0.tar.gz
>
>
> I'm working on getting JBoss going against the Ingres RDBMS database server. I've got some initial config files that can be included as part of the data source configurations. I have other patches for different components, but this issue is just to get two data source definitions added to the jbossas/trunk/connector/src/etc/example-config directory, one for a  local-tx-datasource and one for a xa-datasource.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 13:39:04 2009
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Wed, 1 Jul 2009 13:39:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1000) COMPRESS corrupts
	some messages
In-Reply-To: <7560851.1245854756549.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1061627029.1246469944120.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Reed resolved JGRP-1000.
-------------------------------

    Resolution: Done


Committed to Branch_JGroups_2_4, Branch_JGroups_2_6, and HEAD.

COMPRESS no longer replaces the original message if the compressed version is not smaller.

> COMPRESS corrupts some messages
> -------------------------------
>
>                 Key: JGRP-1000
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1000
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.5
>            Reporter: Dennis Reed
>            Assignee: Dennis Reed
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> COMPRESS.down() stores the compressed message in a temporary buffer the same size as the original message.
> If the compressed size of a message is larger than the original, then part of the message is lost, with no errors reported.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 14:46:51 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 1 Jul 2009 14:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1860) adda check and
 don't process EJB2 metadata in Ejb3AnnotationHandler
In-Reply-To: <1456911370.1246456851425.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1908706879.1246474011894.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1860:
-----------------------------------

    Affects Version/s: 1.1.8


> adda check and don't process EJB2 metadata in Ejb3AnnotationHandler
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1860
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1860
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: core
>    Affects Versions: 1.1.8
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.1.9
>
>
> This is inspired by JBMETA-208. As I explained in JBMETA-208, EJB2 metadata shouldn't even get that far. But I'll add one if-statement anyway to make sure we don't run into an issue like that again.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 14:12:03 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 1 Jul 2009 14:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1257105679.1246471923451.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474506#action_12474506 ] 

Carlo de Wolf commented on JBMETA-208:
--------------------------------------

EJB 3.0 page 497:
"All EJB deployment descriptors must indicate the ejb-jar schema by using the Java EE namespace:

http://java.sun.com/xml/ns/javaee

and by indicating the version of the schema by using the version element as shown below:

    <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
          http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
      version="3.0">
      ...
    </ejb-jar>"

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <ejb-jar version="3.0"
>     xmlns="http://java.sun.com/xml/ns/javaee"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 13:50:52 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 1 Jul 2009 13:50:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <353309018.1246470652029.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474503#action_12474503 ] 

Alexey Loubyansky commented on JBMETA-208:
------------------------------------------

This is what Richard is asking for: "If you have a bean annotated @Stateful or @Stateless in your JAR, but your JAR has an EJB2 deployment descriptor, you should get an error."

> The deployment should have been completely skipped from the EJB3 processing. 

It is now. See related issues.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <ejb-jar version="3.0"
>     xmlns="http://java.sun.com/xml/ns/javaee"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 13:19:51 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Wed, 1 Jul 2009 13:19:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (SECURITY-415)
 ClientLoginModule
 multi-threaded=false should make SecurityContext client side association
In-Reply-To: <12517767.1244524256604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <892470226.1246468791459.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/SECURITY-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474498#action_12474498 ] 

Stefan Guilhen commented on SECURITY-415:
-----------------------------------------

Another possibility is to forbid the use of ClientLoginModule on the server side, as one could easily do SecurityClientFactory.getSecurityClient().performSimpleLogin() to change his security context information. The drawback here is that we would have to clearly document this and it would break applications that currently use the ClientLoginModule on the server side.

> ClientLoginModule multi-threaded=false should make SecurityContext client side association
> ------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-415
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-415
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: JBossSecurity_2.0.3.SP1
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.3.SP2
>
>
> The ClientLoginModule multi-threaded=false option when missing, should set SecurityContextAssociation.setClient()

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

        


From jira-events at lists.jboss.org  Wed Jul  1 14:46:51 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 1 Jul 2009 14:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1860) adda check and
 don't process EJB2 metadata in Ejb3AnnotationHandler
In-Reply-To: <1456911370.1246456851425.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <324093341.1246474011804.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1860:
-----------------------------------

    Component/s: core


> adda check and don't process EJB2 metadata in Ejb3AnnotationHandler
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1860
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1860
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: core
>    Affects Versions: 1.1.8
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.1.9
>
>
> This is inspired by JBMETA-208. As I explained in JBMETA-208, EJB2 metadata shouldn't even get that far. But I'll add one if-statement anyway to make sure we don't run into an issue like that again.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 10:21:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 1 Jul 2009 10:21:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-101) SJC/RADeployer:
	Annotations
Message-ID: <387057390.1246458111738.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC/RADeployer: Annotations
---------------------------

                 Key: JBJCA-101
                 URL: https://jira.jboss.org/jira/browse/JBJCA-101
             Project: JBoss JCA
          Issue Type: Task
          Components: Deployer
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Handle annotations in the resource adapter to build a complete metadata model for the adapter.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 10:17:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 1 Jul 2009 10:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-100) SJC/RADeployer:
	Classloading
Message-ID: <855624937.1246457871714.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC/RADeployer: Classloading
----------------------------

                 Key: JBJCA-100
                 URL: https://jira.jboss.org/jira/browse/JBJCA-100
             Project: JBoss JCA
          Issue Type: Task
          Components: Deployer
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Add a classloader to each deployment unit in the SJC resource adapter deployer.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 10:23:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 1 Jul 2009 10:23:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-102) SJC/RADeployer:
	Merge metadata
Message-ID: <2016998490.1246458231392.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC/RADeployer: Merge metadata
------------------------------

                 Key: JBJCA-102
                 URL: https://jira.jboss.org/jira/browse/JBJCA-102
             Project: JBoss JCA
          Issue Type: Task
          Components: Deployer
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Merge the metadata from the XML and the annotations into a single model.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 06:04:31 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Wed, 1 Jul 2009 06:04:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1675) add netty
 servlet firewall support when available.
Message-ID: <636963632.1246442671919.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

add netty servlet firewall support when available.
--------------------------------------------------

                 Key: JBMESSAGING-1675
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1675
             Project: JBoss Messaging
          Issue Type: Task
    Affects Versions: 2.0.0.beta3
            Reporter: Andy Taylor
            Assignee: Andy Taylor
             Fix For: 2.0.0




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

        


From jira-events at lists.jboss.org  Wed Jul  1 10:00:51 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 1 Jul 2009 10:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1860) adda check and
 don't process EJB2 metadata in Ejb3AnnotationHandler
Message-ID: <1456911370.1246456851425.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

adda check and don't process EJB2 metadata in Ejb3AnnotationHandler
-------------------------------------------------------------------

                 Key: EJBTHREE-1860
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1860
             Project: EJB 3.0
          Issue Type: Task
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: 1.1.9


This is inspired by JBMETA-208. As I explained in JBMETA-208, EJB2 metadata shouldn't even get that far. But I'll add one if-statement anyway to make sure we don't run into an issue like that again.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 10:08:51 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 1 Jul 2009 10:08:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7070) EJB3 version check
 should be based on JBossMetaData.isEJB3x()
Message-ID: <1783378528.1246457331361.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

EJB3 version check should be based on JBossMetaData.isEJB3x()
-------------------------------------------------------------

                 Key: JBAS-7070
                 URL: https://jira.jboss.org/jira/browse/JBAS-7070
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB3
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: JBossAS-5.2.0.Beta1


org.jboss.ejb3.deployers.Ejb3Deployer does it this way: !(metaData.isEJB2x() || metaData.isEJB1x()). Instead, it should use metaData.isEJB3x(). This is inspired by JBMETA-208.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 06:37:31 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Wed, 1 Jul 2009 06:37:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2153) ODE integration
Message-ID: <1874338443.1246444651278.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

ODE integration
---------------

                 Key: JBRULES-2153
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2153
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-compiler (flow), drools-core (flow)
            Reporter: Kris Verlaenen
            Assignee: Kris Verlaenen
             Fix For: 5.1.0.M1


Allow the execution of WS-BPEL processes by embedding the Apache ODE engine.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 06:02:31 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Wed, 1 Jul 2009 06:02:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1674) add netty
	https support
Message-ID: <91041005.1246442551264.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

add netty https support
-----------------------

                 Key: JBMESSAGING-1674
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1674
             Project: JBoss Messaging
          Issue Type: Task
    Affects Versions: 2.0.0.beta3
            Reporter: Andy Taylor
            Assignee: Andy Taylor
             Fix For: 2.0.0


Netty has has support added for https when using the servlet transport. we need to make sure we support this fully and add an example. This will be available in netty 2.0.0.CR2 upwards

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

        


From jira-events at lists.jboss.org  Wed Jul  1 12:33:07 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Wed, 1 Jul 2009 12:33:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1429795558.1246465987071.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-6185:
---------------------------------

    Labels: EmbJopr1_3  (was: )


> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Shelly McGowan
>            Priority: Blocker
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 11:17:51 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Wed, 1 Jul 2009 11:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (SECURITY-415)
 ClientLoginModule
 multi-threaded=false should make SecurityContext client side association
In-Reply-To: <12517767.1244524256604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <929026014.1246461471460.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/SECURITY-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474471#action_12474471 ] 

Stefan Guilhen commented on SECURITY-415:
-----------------------------------------

Calling SecurityAssociationContext.setClient() causes many problems when the ClientLoginModule is used on the server side. Consider the ClientLoginModuleEJBUnitCase, where the test calls a bean and this bean performs a login() using the ClientLoginModule. As the multi-threaded property was not set, the module calls setClient() on SecurityContextAssociation, causing all server threads to use the *same* static variable to hold the security contexts. Of course this leads to a huge security flaw.

In my opinion we should not use any variables to differentiate between server and client usage. I think we should have different classes, perhaps different login modules - a ServerLoginModule that never changes the way SecurityContextAssociation works. If we are to use the same module, then we would need separate SecurityContextAssociation implementations - a server side one that stores all contexts in ThreadLocal variables, and a client-side one that offers a vm-wide association of security context via a static variable. In this approach, calling setClient() on the server-side implementation would cause no effects.

> ClientLoginModule multi-threaded=false should make SecurityContext client side association
> ------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-415
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-415
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: JBossSecurity_2.0.3.SP1
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.3.SP2
>
>
> The ClientLoginModule multi-threaded=false option when missing, should set SecurityContextAssociation.setClient()

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

        


From jira-events at lists.jboss.org  Wed Jul  1 11:27:52 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 1 Jul 2009 11:27:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1617) JBM does not
 handle
 java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes()
 when copying a foreign message.
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <400946656.1246462072033.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reopened JBMESSAGING-1617:
-------------------------------------



As discussed with Tim, the current fix, which adds a catch of UnsupportedOperationException, will have big perf impact when the foreign message doesn't support the bytesID. The better way to do is making it an optional behavior by introducing a property into the fix.

Re-open it for the new solution.


> JBM does not handle java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes() when copying a foreign message.
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Some providers can throw UnsupportedOperationException from getCorrelationIDBytes(). This is called in the foreign message constructor of a JBM message. Currently JBM will fail to copy the message since the exception is not handled.
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

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

       



From jira-events at lists.jboss.org  Wed Jul  1 11:31:52 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Wed, 1 Jul 2009 11:31:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMICROCONT-446)
 bean-deployer xsds don't contain web references
In-Reply-To: <12930376.1245605276537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <733550969.1246462312478.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMICROCONT-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474476#action_12474476 ] 

Wolfgang Knauf commented on JBMICROCONT-446:
--------------------------------------------

About the schema locations in included files: at least Eclipse/WebToolsPlatform does not take the location of the including document, it will complain with a "cannot find" error. Same problem occured for jboss_5_1.xsd, which includes jboss_common_5_1.xsd and which is fixed now.
E.g. the Sun JavaEE xsds all have schema locations with full path in the xsd:includes.

> bean-deployer xsds don't contain web references
> -----------------------------------------------
>
>                 Key: JBMICROCONT-446
>                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-446
>             Project: JBoss Microcontainer
>          Issue Type: Bug
>            Reporter: Wolfgang Knauf
>            Assignee: Kabir Khan
>
> bean-deployer_2_0.xsd:
>    <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">
> =>should point. 
>    <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">
> The comment for a sample instance should also contain a schema location attribute:
>          <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xmlns="urn:jboss:bean-deployer:2.0"
>             xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">
> ==================
> bean-deployer_1_0.xsd:
> The comment for a sample instance should point to the web schema location:
>          <deployment
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
>             xmlns="urn:jboss:bean-deployer">
> =================
> policy_1_0.xsd:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
> should be:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>
> =================
> bean-deployer_2_0.xsd raises validation errors in Eclipse:
> -rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
> -src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
> According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426 ), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 11:31:52 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 1 Jul 2009 11:31:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1288177984.1246462312842.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474477#action_12474477 ] 

jaikiran pai commented on JBMETA-208:
-------------------------------------

>> And if it's EJB2 then does it make sense to look into each class in the JAR to make sure there are no EJB3 annotations? Because this is what you are asking for.

>From my understanding, that's *not* what Richard is asking for. I guess, the point he is trying to make is (based on what i see in the forum post) that some of the deployers processed this as a EJB3 deployment where as the others did not process it. Effectively, this resulted in the deployment having insufficient metadata. As shown in the logs, in that post, we did create the EJB3 services for this deployment (we shouldn't have):

2009-06-15 13:03:33,687 INFO  [org.jboss.ejb3.deployers.JBossASKernel] (main) installing bean: jboss
.j2ee:ear=avant-ss-app.ear,jar=avant-ss-ejb.jar,name=AdviserBean,service=EJB3

The deployment should have been completely skipped from the EJB3 processing. 

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <ejb-jar version="3.0"
>     xmlns="http://java.sun.com/xml/ns/javaee"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 11:29:52 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 1 Jul 2009 11:29:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
In-Reply-To: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2081539651.1246462192366.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7051:
-------------------------------

    Assignee: Scott M Stark  (was: Jason T. Greene)


> ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7051
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ejb3-tutorial-mdb.jar
>
>
> This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:
> 1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.
> 2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:
> container=JBossMQ|JBossMessaging
> which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.
> Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:
> 15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
> ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
> rvice=Queue, parent=JBoss EAP 5 (default)]
> org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
>         at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
>         at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
> rceManager.java:235)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
> figurationUIBean.java:144)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.seam.util.Reflections.invoke(Reflections.java:22)
>         at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
>         at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
> tion(ResourceConfigurationUIBean_$$_javassist_12.java)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
>         at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
>         at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
>         at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
>         at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
>         at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
>         at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
>         at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
>         at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
>         at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
>         at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>         at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>         at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
>         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:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
> a:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
> :70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
> operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
> a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
> ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
> ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
>         ... 84 more

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

        


From jira-events at lists.jboss.org  Wed Jul  1 11:31:52 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 1 Jul 2009 11:31:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7050)
 "ClassNotFoundException:
 org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote
 calls to ManagementView.getTemplate()
Message-ID: <2009724766.1246462312306.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7050:
-------------------------------

        Summary: "ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote calls to ManagementView.getTemplate()  (was: Unable to create any kind of datasource or connection factory)
    Component/s: ProfileService


> "ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote calls to ManagementView.getTemplate()
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7050
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7050
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to create a datasource in AS5 using JON, the following exception occurs:
> java.lang.ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo                                                                                               
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)                                                                                            
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)                                                                                                 
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)                                                                                                                         
>         at java.lang.Class.forName0(Native Method)                                                                                                                                               
>         at java.lang.Class.forName(Class.java:247)                                                                                                                                               
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)                                                                   
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)                                                                                                               
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)                                                                                                                  
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)                                                                                                  
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)                                                                                                               
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)                                                                                                              
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)                                                                                                                 
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)                                                        
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)                                                                  
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)                                                                              
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)                                                                                     
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)                                                                        
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)                                                                             
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)                                                                                                 
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                                    
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                                     
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                            
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                          
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                        
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)                                                                                                                
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)                                                             
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> I was only able to find this class in jboss-embedded-all maven module.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 03:37:43 2009
From: jira-events at lists.jboss.org (Christian Daszenies (JIRA))
Date: Wed, 1 Jul 2009 03:37:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7068) Wrong timeout-valiue
 in OracleValidConnectionChecker
Message-ID: <699957358.1246433863204.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Wrong timeout-valiue in OracleValidConnectionChecker
----------------------------------------------------

                 Key: JBAS-7068
                 URL: https://jira.jboss.org/jira/browse/JBAS-7068
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA service
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Christian Daszenies
            Assignee: Jesper Pedersen


OracleValidConnectionChecker calls 
oracle.jdbc.driver.OracleConnection.pingDatabase(5000) - 5000 is used as timeout in seconds! by pingDatabase
furthermore it would be nice if the timeout would be configurable (or at least easy to override)

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

        


From jira-events at lists.jboss.org  Wed Jul  1 04:07:31 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 1 Jul 2009 04:07:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-208) Provide an annotation
 based tutorial for JBossXB
Message-ID: <1932767477.1246435651400.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Provide an annotation based tutorial for JBossXB
------------------------------------------------

                 Key: JBXB-208
                 URL: https://jira.jboss.org/jira/browse/JBXB-208
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
            Reporter: Thomas Diesler


You've specified the namespace using JBossXmlSchema annotation. Which is correct. You should still add namespace element to the XmlRootElement annotation, which is a bit confusing having JBossXmlSchema. You don't have to do that XmlElement annotations.

Unfortunately, we don't have JAXB tutorial for JBossXB. But you can find one for JAXB on Sun's web-site and use javadoc. For examples you can see tests in XB http://anonsvn.jboss.org/repos/common/jbossxb/trunk/src/test/java/org/jboss/test/xb/builder/object/

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

        


From jira-events at lists.jboss.org  Wed Jul  1 05:37:31 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 1 Jul 2009 05:37:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1531) Consider
 multi-thread replication
In-Reply-To: <32708745.1236102742737.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2064547041.1246441051660.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reopened JBMESSAGING-1531:
--------------------------------------



> Consider multi-thread replication
> ---------------------------------
>
>                 Key: JBMESSAGING-1531
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1531
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.1.0.beta
>
>
> Because of the indeterminism of multi-threading, replication is performed over a single thread which has consequences for throughput.
> Multi-thread replication is a very tricky area but we should consider possible approaches here

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

        


From jira-events at lists.jboss.org  Wed Jul  1 05:39:31 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 1 Jul 2009 05:39:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1531) Consider
 multi-thread replication
In-Reply-To: <32708745.1236102742737.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1419063938.1246441171474.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1531.
------------------------------------

    Resolution: Duplicate Issue


> Consider multi-thread replication
> ---------------------------------
>
>                 Key: JBMESSAGING-1531
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1531
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Because of the indeterminism of multi-threading, replication is performed over a single thread which has consequences for throughput.
> Multi-thread replication is a very tricky area but we should consider possible approaches here

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

        


From jira-events at lists.jboss.org  Wed Jul  1 05:37:31 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 1 Jul 2009 05:37:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1531) Consider
 multi-thread replication
In-Reply-To: <32708745.1236102742737.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1014301418.1246441051553.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1531.
------------------------------------

    Resolution: Duplicate Issue


> Consider multi-thread replication
> ---------------------------------
>
>                 Key: JBMESSAGING-1531
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1531
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.1.0.beta
>
>
> Because of the indeterminism of multi-threading, replication is performed over a single thread which has consequences for throughput.
> Multi-thread replication is a very tricky area but we should consider possible approaches here

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

        


From jira-events at lists.jboss.org  Wed Jul  1 05:39:31 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 1 Jul 2009 05:39:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1531) Consider
 multi-thread replication
In-Reply-To: <32708745.1236102742737.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1253972522.1246441171361.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated JBMESSAGING-1531:
-------------------------------------

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


> Consider multi-thread replication
> ---------------------------------
>
>                 Key: JBMESSAGING-1531
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1531
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Because of the indeterminism of multi-threading, replication is performed over a single thread which has consequences for throughput.
> Multi-thread replication is a very tricky area but we should consider possible approaches here

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

        


From jira-events at lists.jboss.org  Wed Jul  1 08:50:06 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 1 Jul 2009 08:50:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4905) Resolve EJB3 / Web
 Service integration issues
In-Reply-To: <10015790.1193234941460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1227800467.1246452606634.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved JBAS-4905.
---------------------------------

    Fix Version/s:     (was: Backlog)
       Resolution: Out of Date


The WebServiceRef usage should not be an issue anymore. Other potential JBossWS integration issues should be raised individually.

> Resolve EJB3 / Web Service integration issues
> ---------------------------------------------
>
>                 Key: JBAS-4905
>                 URL: https://jira.jboss.org/jira/browse/JBAS-4905
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>            Assignee: Carlo de Wolf
>
> This is a container for relevant ejb3/jbossws integration issues

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

        


From jira-events at lists.jboss.org  Wed Jul  1 03:41:31 2009
From: jira-events at lists.jboss.org (Christian Daszenies (JIRA))
Date: Wed, 1 Jul 2009 03:41:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7069)
 BaseWrapperManagedConnection
 tries to close a probaby unusable connection without any timeouts
Message-ID: <1307120006.1246434091331.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

BaseWrapperManagedConnection tries to close a probaby unusable connection without any timeouts
----------------------------------------------------------------------------------------------

                 Key: JBAS-7069
                 URL: https://jira.jboss.org/jira/browse/JBAS-7069
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.2.3.GA
            Reporter: Christian Daszenies


org/jboss/resource/adapter/jdbc/BaseWrapperManagedConnection calls con.close() in destroy()  on a probably unusable and not responding connection.

destroy() is called when a (OracleValid)ConnectionChecker marks a connection as unusable, in our case because of a timeout in isValidConnection(Connection)
when BaseWrapperManagedConnection calls close() on the same connection the process hangs infinitely



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

        


From jira-events at lists.jboss.org  Wed Jul  1 10:02:52 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 1 Jul 2009 10:02:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-1860) adda check and
 don't process EJB2 metadata in Ejb3AnnotationHandler
In-Reply-To: <1456911370.1246456851425.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1741263283.1246456972121.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed EJBTHREE-1860.
---------------------------------------

    Resolution: Done


Done.

> adda check and don't process EJB2 metadata in Ejb3AnnotationHandler
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1860
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1860
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.1.9
>
>
> This is inspired by JBMETA-208. As I explained in JBMETA-208, EJB2 metadata shouldn't even get that far. But I'll add one if-statement anyway to make sure we don't run into an issue like that again.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 10:10:51 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 1 Jul 2009 10:10:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7070) EJB3 version check
 should be based on JBossMetaData.isEJB3x()
In-Reply-To: <1783378528.1246457331361.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <723013466.1246457451535.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBAS-7070.
-----------------------------------

    Resolution: Done


Done.

> EJB3 version check should be based on JBossMetaData.isEJB3x()
> -------------------------------------------------------------
>
>                 Key: JBAS-7070
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7070
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> org.jboss.ejb3.deployers.Ejb3Deployer does it this way: !(metaData.isEJB2x() || metaData.isEJB1x()). Instead, it should use metaData.isEJB3x(). This is inspired by JBMETA-208.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 10:27:51 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 1 Jul 2009 10:27:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1732) Pooling
 strategy and configuration information needed at runtime
In-Reply-To: <13056858.1235139524527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <183589543.1246458471360.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474465#action_12474465 ] 

Carlo de Wolf commented on EJBTHREE-1732:
-----------------------------------------

The pooling (and caching) configuration must be visible through JMX / console.

> Pooling strategy and configuration information needed at runtime
> ----------------------------------------------------------------
>
>                 Key: EJBTHREE-1732
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1732
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: ejb3
>    Affects Versions: AS 4.2.3.GA, 1.0.0-Beta10
>            Reporter: Galder Zamarreno
>
> There needs to be a way at runtime to see what pooling strategy (including configuration options) an 
> EJB3 bean is using. Currently, the only way to see this is by enabling TRACE on org.jboss.ejb3 and 
> making an invocation to that EJB3 bean.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 09:50:51 2009
From: jira-events at lists.jboss.org (Jaroslaw Kijanowski (JIRA))
Date: Wed, 1 Jul 2009 09:50:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2154) equality
 assertion behavior not supported in streams
Message-ID: <1255777094.1246456251487.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

equality assertion behavior not supported in streams
----------------------------------------------------

                 Key: JBRULES-2154
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2154
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler (fusion)
    Affects Versions: 5.0.1.FINAL
            Reporter: Jaroslaw Kijanowski
            Assignee: Edson Tirelli


Happens with 5.0.1 and trunk 27324

I've configured my knowledge base to use the EQUALITY assertion behavior.
When I insert two equal facts into the session, only one gets processed (objects and their fact handles are equal).
However when I insert two equal facts via streams, my rule fires twice (objects are equal, but their fact handles are not). Isn't equality assertion behavior supported when using streams?

Attaching rule, model and test class.
If you run it you will see following output:

equal
1

That's expected. If you remove the comment from
WorkingMemoryEntryPoint stream = ...
FactHandle fh1 = stream.insert(message1);
FactHandle fh2 = stream.insert(message2);

and comment out
FactHandle fh1 = ksession.insert(message1);
FactHandle fh2 = ksession.insert(message2);

and modify the rule file to use streams (just remove comments)

you will get this output:

1
1

Means the rule fired twice.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 03:29:31 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 1 Jul 2009 03:29:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-202) BeansDeployer
 cannot be recycled
In-Reply-To: <1676631077.1246377488627.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <940889806.1246433371297.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBDEPLOY-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474392#action_12474392 ] 

Thomas Diesler commented on JBDEPLOY-202:
-----------------------------------------

JBossXBHelper helper fixed in jbossxb-2.0.2-SNAPSHOT

> BeansDeployer cannot be recycled
> --------------------------------
>
>                 Key: JBDEPLOY-202
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-202
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: classloading
>    Affects Versions: JBDEPLOY-2.0.5.GA
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For:  JBDEPLOY-2.2.x
>
>
> Caused by: java.lang.ClassCastException
> at java.lang.Class.cast(Class.java:2990)
> at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:215)
> at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:170)
> at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:132)
> at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:118)
> at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parseAndInit(AbstractVFSParsingDeployer.java:256)
> at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:239)
> at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:330)

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

        


From jira-events at lists.jboss.org  Wed Jul  1 03:33:31 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 1 Jul 2009 03:33:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-202) BeansDeployer
 cannot be recycled
In-Reply-To: <1676631077.1246377488627.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1711804327.1246433611788.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBDEPLOY-202.
-------------------------------------

    Resolution: Done


Done.

* Allow overwrite of JBossXBHelper. 
* Use jbossxb-2.0.2-SNAPSHOT

in Branch_2_0 and trunk (-r90735)

> BeansDeployer cannot be recycled
> --------------------------------
>
>                 Key: JBDEPLOY-202
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-202
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: classloading
>    Affects Versions: JBDEPLOY-2.0.5.GA
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For:  JBDEPLOY-2.2.x
>
>
> Caused by: java.lang.ClassCastException
> at java.lang.Class.cast(Class.java:2990)
> at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:215)
> at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:170)
> at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:132)
> at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:118)
> at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parseAndInit(AbstractVFSParsingDeployer.java:256)
> at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:239)
> at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:330)

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

        


From jira-events at lists.jboss.org  Wed Jul  1 09:52:51 2009
From: jira-events at lists.jboss.org (Jaroslaw Kijanowski (JIRA))
Date: Wed, 1 Jul 2009 09:52:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2154) equality
 assertion behavior not supported in streams
In-Reply-To: <1255777094.1246456251487.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <601196211.1246456371842.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jaroslaw Kijanowski updated JBRULES-2154:
-----------------------------------------

    Component/s: drools-core (fusion)
                     (was: drools-compiler (fusion))


> equality assertion behavior not supported in streams
> ----------------------------------------------------
>
>                 Key: JBRULES-2154
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2154
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (fusion)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Jaroslaw Kijanowski
>            Assignee: Edson Tirelli
>         Attachments: DroolsTest.java, Message.java, Sample.drl
>
>
> Happens with 5.0.1 and trunk 27324
> I've configured my knowledge base to use the EQUALITY assertion behavior.
> When I insert two equal facts into the session, only one gets processed (objects and their fact handles are equal).
> However when I insert two equal facts via streams, my rule fires twice (objects are equal, but their fact handles are not). Isn't equality assertion behavior supported when using streams?
> Attaching rule, model and test class.
> If you run it you will see following output:
> equal
> 1
> That's expected. If you remove the comment from
> WorkingMemoryEntryPoint stream = ...
> FactHandle fh1 = stream.insert(message1);
> FactHandle fh2 = stream.insert(message2);
> and comment out
> FactHandle fh1 = ksession.insert(message1);
> FactHandle fh2 = ksession.insert(message2);
> and modify the rule file to use streams (just remove comments)
> you will get this output:
> 1
> 1
> Means the rule fired twice.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 10:32:03 2009
From: jira-events at lists.jboss.org (Prem Stephen (JIRA))
Date: Wed, 1 Jul 2009 10:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2154) equality
 assertion behavior not supported in streams
In-Reply-To: <1255777094.1246456251487.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <956434639.1246458723138.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474466#action_12474466 ] 

Prem Stephen commented on JBRULES-2154:
---------------------------------------

Kindly let me know if this issue is related as well
https://jira.jboss.org/jira/browse/GUVNOR-354

> equality assertion behavior not supported in streams
> ----------------------------------------------------
>
>                 Key: JBRULES-2154
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2154
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (fusion)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Jaroslaw Kijanowski
>            Assignee: Edson Tirelli
>         Attachments: DroolsTest.java, Message.java, Sample.drl
>
>
> Happens with 5.0.1 and trunk 27324
> I've configured my knowledge base to use the EQUALITY assertion behavior.
> When I insert two equal facts into the session, only one gets processed (objects and their fact handles are equal).
> However when I insert two equal facts via streams, my rule fires twice (objects are equal, but their fact handles are not). Isn't equality assertion behavior supported when using streams?
> Attaching rule, model and test class.
> If you run it you will see following output:
> equal
> 1
> That's expected. If you remove the comment from
> WorkingMemoryEntryPoint stream = ...
> FactHandle fh1 = stream.insert(message1);
> FactHandle fh2 = stream.insert(message2);
> and comment out
> FactHandle fh1 = ksession.insert(message1);
> FactHandle fh2 = ksession.insert(message2);
> and modify the rule file to use streams (just remove comments)
> you will get this output:
> 1
> 1
> Means the rule fired twice.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 09:52:51 2009
From: jira-events at lists.jboss.org (Jaroslaw Kijanowski (JIRA))
Date: Wed, 1 Jul 2009 09:52:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2154) equality
 assertion behavior not supported in streams
In-Reply-To: <1255777094.1246456251487.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <443430062.1246456371954.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jaroslaw Kijanowski updated JBRULES-2154:
-----------------------------------------

    Attachment: DroolsTest.java
                Message.java
                Sample.drl


> equality assertion behavior not supported in streams
> ----------------------------------------------------
>
>                 Key: JBRULES-2154
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2154
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (fusion)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Jaroslaw Kijanowski
>            Assignee: Edson Tirelli
>         Attachments: DroolsTest.java, Message.java, Sample.drl
>
>
> Happens with 5.0.1 and trunk 27324
> I've configured my knowledge base to use the EQUALITY assertion behavior.
> When I insert two equal facts into the session, only one gets processed (objects and their fact handles are equal).
> However when I insert two equal facts via streams, my rule fires twice (objects are equal, but their fact handles are not). Isn't equality assertion behavior supported when using streams?
> Attaching rule, model and test class.
> If you run it you will see following output:
> equal
> 1
> That's expected. If you remove the comment from
> WorkingMemoryEntryPoint stream = ...
> FactHandle fh1 = stream.insert(message1);
> FactHandle fh2 = stream.insert(message2);
> and comment out
> FactHandle fh1 = ksession.insert(message1);
> FactHandle fh2 = ksession.insert(message2);
> and modify the rule file to use streams (just remove comments)
> you will get this output:
> 1
> 1
> Means the rule fired twice.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 09:52:52 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 1 Jul 2009 09:52:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1630882893.1246456372318.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474455#action_12474455 ] 

Alexey Loubyansky commented on JBMETA-208:
------------------------------------------

For the record, I am adding a check to Ejb3AnnotationHandler (right before the possible JBMETA-4 warning) whether the metadata is version 3.x and if it's not an exception is thrown:
"Attempt to process non-EJB3.x EJB-JAR metadata as EJB3.x for deployment " + deployment.getName()

But then again I am fixing other parts in the deployers where EJB2 metadata should not pass through. So, EJB2 metadata won't reach Ejb3AnnotationHandler.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <ejb-jar version="3.0"
>     xmlns="http://java.sun.com/xml/ns/javaee"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 09:21:51 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 1 Jul 2009 09:21:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMICROCONT-446)
 bean-deployer xsds don't contain web references
In-Reply-To: <12930376.1245605276537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2032267583.1246454511494.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMICROCONT-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474450#action_12474450 ] 

David Lloyd commented on JBMICROCONT-446:
-----------------------------------------

I recently changed the <xsd:redefine> in bean-deployer_2_0.xsd to <xsd:include>; but I don't see why there must be an absolute URL for the location.  My understanding is that the schema location will be resolved against the including schema's location (which is exactly what we want, no?)

Also these items:

-rcase-RecurseLax.2: There is not a complete functional mapping between the particles.
-src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated: 'rcase-RecurseLax.2'. 

should be fixed by that change.(at least, IDEA doesn't complain about it anymore).

> bean-deployer xsds don't contain web references
> -----------------------------------------------
>
>                 Key: JBMICROCONT-446
>                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-446
>             Project: JBoss Microcontainer
>          Issue Type: Bug
>            Reporter: Wolfgang Knauf
>            Assignee: Kabir Khan
>
> bean-deployer_2_0.xsd:
>    <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">
> =>should point. 
>    <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">
> The comment for a sample instance should also contain a schema location attribute:
>          <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xmlns="urn:jboss:bean-deployer:2.0"
>             xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">
> ==================
> bean-deployer_1_0.xsd:
> The comment for a sample instance should point to the web schema location:
>          <deployment
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
>             xmlns="urn:jboss:bean-deployer">
> =================
> policy_1_0.xsd:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
> should be:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>
> =================
> bean-deployer_2_0.xsd raises validation errors in Eclipse:
> -rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
> -src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
> According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426 ), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 09:37:51 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 1 Jul 2009 09:37:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <659233423.1246455471457.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474452#action_12474452 ] 

Alexey Loubyansky commented on JBMETA-208:
------------------------------------------

I still don't like it... The thing is we don't want to look whether there are classes that (accidentally or not) have EJB3 annotations in an EJB2 deployment.
When a JAR is deployed, we first look whether there is an ejb-jar.xml. And if it's there we can tell by its version which EJB version this deployment is. And if it's EJB2 then does it make sense to look into each class in the JAR to make sure there are no EJB3 annotations? Because this is what you are asking for. It's rather expensive performance-wise.

I understand it's something that used to work. But it shouldn't have worked in the first place. It should actually be considered a bug in JBoss 4.2.3.GA.

PS: regarding the JBMETA-4 warning, I've found a few places where EJB2 deployment could slip through into the EJB3 deployers layer which I am going to fix. But the warning is actually a different issue which accidentally popped up here.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <ejb-jar version="3.0"
>     xmlns="http://java.sun.com/xml/ns/javaee"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 09:39:51 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 1 Jul 2009 09:39:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1617) JBM does not
 handle
 java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes()
 when copying a foreign message.
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1575829431.1246455591802.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1617.
-----------------------------------



done

> JBM does not handle java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes() when copying a foreign message.
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Some providers can throw UnsupportedOperationException from getCorrelationIDBytes(). This is called in the foreign message constructor of a JBM message. Currently JBM will fail to copy the message since the exception is not handled.
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

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

       



From jira-events at lists.jboss.org  Wed Jul  1 10:17:51 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 1 Jul 2009 10:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1006) Shared transport:
 shunned multiple channels can not reconnect
In-Reply-To: <1360522755.1246439551381.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <544314707.1246457871592.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474460#action_12474460 ] 

Vladimir Blagojevic commented on JGRP-1006:
-------------------------------------------

Commit set on BRANCH 2.6:
Configurator.java 1.28.4.9

> Shared transport: shunned multiple channels can not reconnect 
> --------------------------------------------------------------
>
>                 Key: JGRP-1006
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1006
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6
>            Reporter: Vladimir Blagojevic
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11
>
>
> Brian Stansberry said:
> One of the EJB3/AS integration testsuite runs hit a JGroups problem last 
> night. *Looks like* some issue between the two AS nodes (127.0.0.1 and 
> 127.0.0.2) in the test caused the channels in one node to be 
> suspected/reconnect. Which didn't go well -- which is the subject of 
> this thread.
> I have the server logs from both, which record at INFO or above; if 
> anyone wants them, ping me. Here are the highlights:
> 1) Both nodes connect 4 channels as part of AS startup: 3 using a shared 
> transport UDP stack (for JBC, HAPartition, JBM) and one TCP one for JBM.
> 2) A bunch of test cases then execute, each deploys an EJB3 jar on each 
> node in turn, which in turn causes another JBC channel to be created and 
> connect at test start and disconnect and close at test end. This channel 
> uses the same shared  transport as the other 3, so now there are four 
> channels using that shared transport.
> 3) This create/close cycle continues a while, until on one node there is 
> some issue that results in one of the 4 UDP channels suspecting its peer 
> and all 4 UDP channels getting a new view:
> 13:23:58,150 INFO  [DefaultPartition] Suspected member: 127.0.0.1:40089
> 13:23:58,257 INFO  [GroupMember] 
> org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 4cfcb4de 
> got new view [127.0.0.2:42088|2] [127.0.0.2:42088], old view is 
> [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088]
> 13:23:58,257 INFO  [GroupMember] I am (127.0.0.2:42088)
> 13:23:58,265 INFO  [DefaultPartition] New cluster view for partition 
> DefaultPartition (id: 2, delta: -1) : [127.0.0.2:1099]
> 13:23:58,275 INFO  [MessagingPostOffice] JBoss Messaging is failing over 
> for failed node 0. If there are many messages to reload this may take 
> some time...
> 13:23:58,442 INFO  [DefaultPartition] I am (127.0.0.2:1099) received 
> membershipChanged event:
> 13:23:58,442 INFO  [DefaultPartition] Dead members: 1 ([127.0.0.1:1099])
> 13:23:58,442 INFO  [DefaultPartition] New Members : 0 ([])
> 13:23:58,442 INFO  [DefaultPartition] All Members : 1 ([127.0.0.2:1099])
> 13:23:58,581 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|2] [127.0.0.2:42088]
> 13:23:58,620 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|2] [127.0.0.2:42088]
> 13:24:00,260 WARN  [GMS] 127.0.0.2:42088 failed to collect all ACKs (1) 
> for mcasted view [127.0.0.2:42088|2] [127.0.0.2:42088] after 2000ms, 
> missing ACKs from [127.0.0.2:42088] (received=[]), 
> local_addr=127.0.0.2:42088
> 13:24:00,661 INFO  [MessagingPostOffice] JBoss Messaging failover completed
> 13:24:00,662 INFO  [GroupMember] Dead members: 1 ([127.0.0.1:40089])
> 13:24:00,662 INFO  [GroupMember] All Members : 1 ([127.0.0.2:42088])
> 4) At some point the suspected node realizes it is suspected and the 4 
> UDP channels decide to reconnect, two at about the same time and the 
> other two w/in 55 ms of the first two:
> 13:24:39,294 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,295 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,315 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,339 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,359 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,360 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,380 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 5) This is where things break down.  It looks like one of the 4 channels 
> is able to get a local_addr, but the others get null. Perhaps a 
> concurrency bug in Configurator.startProtocolStack? (Note the first 2 
> lines below have to do with the independent TCP channel used by JBM; I 
> post them for completeness.)
> 13:24:39,568 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:39,959 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:40,833 WARN  [GMS]
> 13:24:40,834 WARN  [GMS]
> 13:24:41,362 INFO  [STDOUT]
> ---------------------------------------------------------
> GMS: address is 127.0.0.1:56000 (cluster=DefaultPartition-SFSBCache)
> ---------------------------------------------------------
> 13:24:41,362 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,488 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|3] [127.0.0.2:42088, 127.0.0.1:56000]
> 13:24:41,564 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,564 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,927 INFO  [LegacyStateTransferIntegrator] Using version 4096
> 13:24:45,941 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
> 13:24:45,993 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:7900, 127.0.0.1:7900]
> 13:24:45,995 WARN  [GMS] merge was supposed to be cancelled at merge 
> participant 127.0.0.1:7900 (merge_id=[127.0.0.1:7900|1246037080987]), 
> but it is not since merge ids do not match
> 13:24:46,029 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
> 13:24:46,029 WARN  [GMS] resume([127.0.0.1:40089|1246037080833]) does 
> not match null
> 6) Thereafter, there is continual looping of the CloserThread as it 
> tries to connect a channel, fails due to local_addr == null, waits 1 sec 
> and tries again, which goes on for hours:
> 13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> As I said, I suspect a concurrency issue that's resulting in one channel 
> getting a local_addr but thereafter others with the same shared 
> transport get null.
> Hmm, just noticed: the looping in #6 above repeats every 30 secs, not 
> every second. Which is the timeout in JChannel.startStack() :
> /* Wait LOCAL_ADDR_TIMEOUT milliseconds for local_addr to have a 
> non-null value (set by SET_LOCAL_ADDRESS) */
> local_addr=local_addr_promise.getResult(LOCAL_ADDR_TIMEOUT);
> if(local_addr == null) {
>      log.fatal("local_addr is null; cannot connect");
>      throw new ChannelException("local_addr is null");
> }
> So, seems the recurring problem is local_addr_promise isn't getting set, 
> not that it is getting set, but with a null value. *However* the *first* 
> set of FATAL logging occurs just a couple seconds after GMS logs it is 
> going to reconnect. So that first issue where local_addr == null is not 
> due to a timeout.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 10:19:51 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 1 Jul 2009 10:19:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1006) Shared transport:
 shunned multiple channels can not reconnect
In-Reply-To: <1360522755.1246439551381.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <287884442.1246457991632.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Blagojevic resolved JGRP-1006.
---------------------------------------

    Resolution: Done


Resolved on BRANCH 2.6 for 2.6.11 release

> Shared transport: shunned multiple channels can not reconnect 
> --------------------------------------------------------------
>
>                 Key: JGRP-1006
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1006
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6
>            Reporter: Vladimir Blagojevic
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11
>
>
> Brian Stansberry said:
> One of the EJB3/AS integration testsuite runs hit a JGroups problem last 
> night. *Looks like* some issue between the two AS nodes (127.0.0.1 and 
> 127.0.0.2) in the test caused the channels in one node to be 
> suspected/reconnect. Which didn't go well -- which is the subject of 
> this thread.
> I have the server logs from both, which record at INFO or above; if 
> anyone wants them, ping me. Here are the highlights:
> 1) Both nodes connect 4 channels as part of AS startup: 3 using a shared 
> transport UDP stack (for JBC, HAPartition, JBM) and one TCP one for JBM.
> 2) A bunch of test cases then execute, each deploys an EJB3 jar on each 
> node in turn, which in turn causes another JBC channel to be created and 
> connect at test start and disconnect and close at test end. This channel 
> uses the same shared  transport as the other 3, so now there are four 
> channels using that shared transport.
> 3) This create/close cycle continues a while, until on one node there is 
> some issue that results in one of the 4 UDP channels suspecting its peer 
> and all 4 UDP channels getting a new view:
> 13:23:58,150 INFO  [DefaultPartition] Suspected member: 127.0.0.1:40089
> 13:23:58,257 INFO  [GroupMember] 
> org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 4cfcb4de 
> got new view [127.0.0.2:42088|2] [127.0.0.2:42088], old view is 
> [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088]
> 13:23:58,257 INFO  [GroupMember] I am (127.0.0.2:42088)
> 13:23:58,265 INFO  [DefaultPartition] New cluster view for partition 
> DefaultPartition (id: 2, delta: -1) : [127.0.0.2:1099]
> 13:23:58,275 INFO  [MessagingPostOffice] JBoss Messaging is failing over 
> for failed node 0. If there are many messages to reload this may take 
> some time...
> 13:23:58,442 INFO  [DefaultPartition] I am (127.0.0.2:1099) received 
> membershipChanged event:
> 13:23:58,442 INFO  [DefaultPartition] Dead members: 1 ([127.0.0.1:1099])
> 13:23:58,442 INFO  [DefaultPartition] New Members : 0 ([])
> 13:23:58,442 INFO  [DefaultPartition] All Members : 1 ([127.0.0.2:1099])
> 13:23:58,581 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|2] [127.0.0.2:42088]
> 13:23:58,620 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|2] [127.0.0.2:42088]
> 13:24:00,260 WARN  [GMS] 127.0.0.2:42088 failed to collect all ACKs (1) 
> for mcasted view [127.0.0.2:42088|2] [127.0.0.2:42088] after 2000ms, 
> missing ACKs from [127.0.0.2:42088] (received=[]), 
> local_addr=127.0.0.2:42088
> 13:24:00,661 INFO  [MessagingPostOffice] JBoss Messaging failover completed
> 13:24:00,662 INFO  [GroupMember] Dead members: 1 ([127.0.0.1:40089])
> 13:24:00,662 INFO  [GroupMember] All Members : 1 ([127.0.0.2:42088])
> 4) At some point the suspected node realizes it is suspected and the 4 
> UDP channels decide to reconnect, two at about the same time and the 
> other two w/in 55 ms of the first two:
> 13:24:39,294 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,295 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,315 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,339 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,359 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,360 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,380 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 5) This is where things break down.  It looks like one of the 4 channels 
> is able to get a local_addr, but the others get null. Perhaps a 
> concurrency bug in Configurator.startProtocolStack? (Note the first 2 
> lines below have to do with the independent TCP channel used by JBM; I 
> post them for completeness.)
> 13:24:39,568 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:39,959 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:40,833 WARN  [GMS]
> 13:24:40,834 WARN  [GMS]
> 13:24:41,362 INFO  [STDOUT]
> ---------------------------------------------------------
> GMS: address is 127.0.0.1:56000 (cluster=DefaultPartition-SFSBCache)
> ---------------------------------------------------------
> 13:24:41,362 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,488 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|3] [127.0.0.2:42088, 127.0.0.1:56000]
> 13:24:41,564 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,564 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,927 INFO  [LegacyStateTransferIntegrator] Using version 4096
> 13:24:45,941 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
> 13:24:45,993 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:7900, 127.0.0.1:7900]
> 13:24:45,995 WARN  [GMS] merge was supposed to be cancelled at merge 
> participant 127.0.0.1:7900 (merge_id=[127.0.0.1:7900|1246037080987]), 
> but it is not since merge ids do not match
> 13:24:46,029 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
> 13:24:46,029 WARN  [GMS] resume([127.0.0.1:40089|1246037080833]) does 
> not match null
> 6) Thereafter, there is continual looping of the CloserThread as it 
> tries to connect a channel, fails due to local_addr == null, waits 1 sec 
> and tries again, which goes on for hours:
> 13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> As I said, I suspect a concurrency issue that's resulting in one channel 
> getting a local_addr but thereafter others with the same shared 
> transport get null.
> Hmm, just noticed: the looping in #6 above repeats every 30 secs, not 
> every second. Which is the timeout in JChannel.startStack() :
> /* Wait LOCAL_ADDR_TIMEOUT milliseconds for local_addr to have a 
> non-null value (set by SET_LOCAL_ADDRESS) */
> local_addr=local_addr_promise.getResult(LOCAL_ADDR_TIMEOUT);
> if(local_addr == null) {
>      log.fatal("local_addr is null; cannot connect");
>      throw new ChannelException("local_addr is null");
> }
> So, seems the recurring problem is local_addr_promise isn't getting set, 
> not that it is getting set, but with a null value. *However* the *first* 
> set of FATAL logging occurs just a couple seconds after GMS logs it is 
> going to reconnect. So that first issue where local_addr == null is not 
> due to a timeout.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 05:12:31 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 1 Jul 2009 05:12:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1006) Shared transport:
 shunned multiple channels can not reconnect
Message-ID: <1360522755.1246439551381.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Shared transport: shunned multiple channels can not reconnect 
--------------------------------------------------------------

                 Key: JGRP-1006
                 URL: https://jira.jboss.org/jira/browse/JGRP-1006
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.6
            Reporter: Vladimir Blagojevic
            Assignee: Vladimir Blagojevic
             Fix For: 2.6.11


Brian Stansberry said:

One of the EJB3/AS integration testsuite runs hit a JGroups problem last 
night. *Looks like* some issue between the two AS nodes (127.0.0.1 and 
127.0.0.2) in the test caused the channels in one node to be 
suspected/reconnect. Which didn't go well -- which is the subject of 
this thread.

I have the server logs from both, which record at INFO or above; if 
anyone wants them, ping me. Here are the highlights:

1) Both nodes connect 4 channels as part of AS startup: 3 using a shared 
transport UDP stack (for JBC, HAPartition, JBM) and one TCP one for JBM.

2) A bunch of test cases then execute, each deploys an EJB3 jar on each 
node in turn, which in turn causes another JBC channel to be created and 
connect at test start and disconnect and close at test end. This channel 
uses the same shared  transport as the other 3, so now there are four 
channels using that shared transport.

3) This create/close cycle continues a while, until on one node there is 
some issue that results in one of the 4 UDP channels suspecting its peer 
and all 4 UDP channels getting a new view:

13:23:58,150 INFO  [DefaultPartition] Suspected member: 127.0.0.1:40089
13:23:58,257 INFO  [GroupMember] 
org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 4cfcb4de 
got new view [127.0.0.2:42088|2] [127.0.0.2:42088], old view is 
[127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088]
13:23:58,257 INFO  [GroupMember] I am (127.0.0.2:42088)
13:23:58,265 INFO  [DefaultPartition] New cluster view for partition 
DefaultPartition (id: 2, delta: -1) : [127.0.0.2:1099]
13:23:58,275 INFO  [MessagingPostOffice] JBoss Messaging is failing over 
for failed node 0. If there are many messages to reload this may take 
some time...
13:23:58,442 INFO  [DefaultPartition] I am (127.0.0.2:1099) received 
membershipChanged event:
13:23:58,442 INFO  [DefaultPartition] Dead members: 1 ([127.0.0.1:1099])
13:23:58,442 INFO  [DefaultPartition] New Members : 0 ([])
13:23:58,442 INFO  [DefaultPartition] All Members : 1 ([127.0.0.2:1099])
13:23:58,581 INFO  [RPCManagerImpl] Received new cluster view: 
[127.0.0.2:42088|2] [127.0.0.2:42088]
13:23:58,620 INFO  [RPCManagerImpl] Received new cluster view: 
[127.0.0.2:42088|2] [127.0.0.2:42088]
13:24:00,260 WARN  [GMS] 127.0.0.2:42088 failed to collect all ACKs (1) 
for mcasted view [127.0.0.2:42088|2] [127.0.0.2:42088] after 2000ms, 
missing ACKs from [127.0.0.2:42088] (received=[]), 
local_addr=127.0.0.2:42088
13:24:00,661 INFO  [MessagingPostOffice] JBoss Messaging failover completed
13:24:00,662 INFO  [GroupMember] Dead members: 1 ([127.0.0.1:40089])
13:24:00,662 INFO  [GroupMember] All Members : 1 ([127.0.0.2:42088])

4) At some point the suspected node realizes it is suspected and the 4 
UDP channels decide to reconnect, two at about the same time and the 
other two w/in 55 ms of the first two:

13:24:39,294 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
SUSPECT message and sending back a HEARTBEAT_ACK
13:24:39,295 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
SUSPECT message and sending back a HEARTBEAT_ACK
13:24:39,315 ERROR [ConnectionTable] failed sending data to 
127.0.0.2:7900: java.net.SocketException: Broken pipe
13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
[127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
[127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
13:24:39,339 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
[127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
13:24:39,359 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
SUSPECT message and sending back a HEARTBEAT_ACK
13:24:39,360 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
SUSPECT message and sending back a HEARTBEAT_ACK
13:24:39,380 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
[127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])


5) This is where things break down.  It looks like one of the 4 channels 
is able to get a local_addr, but the others get null. Perhaps a 
concurrency bug in Configurator.startProtocolStack? (Note the first 2 
lines below have to do with the independent TCP channel used by JBM; I 
post them for completeness.)

13:24:39,568 ERROR [ConnectionTable] failed sending data to 
127.0.0.2:7900: java.net.SocketException: Broken pipe
13:24:39,959 ERROR [ConnectionTable] failed sending data to 
127.0.0.2:7900: java.net.SocketException: Broken pipe
13:24:40,833 WARN  [GMS]
13:24:40,834 WARN  [GMS]
13:24:41,362 INFO  [STDOUT]
---------------------------------------------------------
GMS: address is 127.0.0.1:56000 (cluster=DefaultPartition-SFSBCache)
---------------------------------------------------------
13:24:41,362 FATAL [JChannel] local_addr is null; cannot connect
13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
org.jgroups.ChannelException: local_addr is null
	at org.jgroups.JChannel.startStack(JChannel.java:1631)
	at org.jgroups.JChannel.connect(JChannel.java:366)
	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
org.jgroups.ChannelException: local_addr is null
	at org.jgroups.JChannel.startStack(JChannel.java:1631)
	at org.jgroups.JChannel.connect(JChannel.java:366)
	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
13:24:41,488 INFO  [RPCManagerImpl] Received new cluster view: 
[127.0.0.2:42088|3] [127.0.0.2:42088, 127.0.0.1:56000]
13:24:41,564 FATAL [JChannel] local_addr is null; cannot connect
13:24:41,564 ERROR [JChannel] failure reconnecting to channel, retrying
org.jgroups.ChannelException: local_addr is null
	at org.jgroups.JChannel.startStack(JChannel.java:1631)
	at org.jgroups.JChannel.connect(JChannel.java:366)
	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
13:24:41,927 INFO  [LegacyStateTransferIntegrator] Using version 4096
13:24:45,941 WARN  [GMS] Merge aborted. Merge leader did not get 
MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
13:24:45,993 WARN  [GMS] Merge aborted. Merge leader did not get 
MergeData from all subgroup coordinators [127.0.0.2:7900, 127.0.0.1:7900]
13:24:45,995 WARN  [GMS] merge was supposed to be cancelled at merge 
participant 127.0.0.1:7900 (merge_id=[127.0.0.1:7900|1246037080987]), 
but it is not since merge ids do not match
13:24:46,029 WARN  [GMS] Merge aborted. Merge leader did not get 
MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
13:24:46,029 WARN  [GMS] resume([127.0.0.1:40089|1246037080833]) does 
not match null

6) Thereafter, there is continual looping of the CloserThread as it 
tries to connect a channel, fails due to local_addr == null, waits 1 sec 
and tries again, which goes on for hours:

13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
org.jgroups.ChannelException: local_addr is null
	at org.jgroups.JChannel.startStack(JChannel.java:1631)
	at org.jgroups.JChannel.connect(JChannel.java:366)
	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)


As I said, I suspect a concurrency issue that's resulting in one channel 
getting a local_addr but thereafter others with the same shared 
transport get null.

Hmm, just noticed: the looping in #6 above repeats every 30 secs, not 
every second. Which is the timeout in JChannel.startStack() :

/* Wait LOCAL_ADDR_TIMEOUT milliseconds for local_addr to have a 
non-null value (set by SET_LOCAL_ADDRESS) */
local_addr=local_addr_promise.getResult(LOCAL_ADDR_TIMEOUT);
if(local_addr == null) {
     log.fatal("local_addr is null; cannot connect");
     throw new ChannelException("local_addr is null");
}

So, seems the recurring problem is local_addr_promise isn't getting set, 
not that it is getting set, but with a null value. *However* the *first* 
set of FATAL logging occurs just a couple seconds after GMS logs it is 
going to reconnect. So that first issue where local_addr == null is not 
due to a timeout.



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

        


From jira-events at lists.jboss.org  Wed Jul  1 10:15:52 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 1 Jul 2009 10:15:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1006) Shared transport:
 shunned multiple channels can not reconnect
In-Reply-To: <1360522755.1246439551381.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1586032072.1246457752044.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474459#action_12474459 ] 

Vladimir Blagojevic commented on JGRP-1006:
-------------------------------------------

Added test method: SharedTransportTest#testShunReconnect()

> Shared transport: shunned multiple channels can not reconnect 
> --------------------------------------------------------------
>
>                 Key: JGRP-1006
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1006
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6
>            Reporter: Vladimir Blagojevic
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11
>
>
> Brian Stansberry said:
> One of the EJB3/AS integration testsuite runs hit a JGroups problem last 
> night. *Looks like* some issue between the two AS nodes (127.0.0.1 and 
> 127.0.0.2) in the test caused the channels in one node to be 
> suspected/reconnect. Which didn't go well -- which is the subject of 
> this thread.
> I have the server logs from both, which record at INFO or above; if 
> anyone wants them, ping me. Here are the highlights:
> 1) Both nodes connect 4 channels as part of AS startup: 3 using a shared 
> transport UDP stack (for JBC, HAPartition, JBM) and one TCP one for JBM.
> 2) A bunch of test cases then execute, each deploys an EJB3 jar on each 
> node in turn, which in turn causes another JBC channel to be created and 
> connect at test start and disconnect and close at test end. This channel 
> uses the same shared  transport as the other 3, so now there are four 
> channels using that shared transport.
> 3) This create/close cycle continues a while, until on one node there is 
> some issue that results in one of the 4 UDP channels suspecting its peer 
> and all 4 UDP channels getting a new view:
> 13:23:58,150 INFO  [DefaultPartition] Suspected member: 127.0.0.1:40089
> 13:23:58,257 INFO  [GroupMember] 
> org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 4cfcb4de 
> got new view [127.0.0.2:42088|2] [127.0.0.2:42088], old view is 
> [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088]
> 13:23:58,257 INFO  [GroupMember] I am (127.0.0.2:42088)
> 13:23:58,265 INFO  [DefaultPartition] New cluster view for partition 
> DefaultPartition (id: 2, delta: -1) : [127.0.0.2:1099]
> 13:23:58,275 INFO  [MessagingPostOffice] JBoss Messaging is failing over 
> for failed node 0. If there are many messages to reload this may take 
> some time...
> 13:23:58,442 INFO  [DefaultPartition] I am (127.0.0.2:1099) received 
> membershipChanged event:
> 13:23:58,442 INFO  [DefaultPartition] Dead members: 1 ([127.0.0.1:1099])
> 13:23:58,442 INFO  [DefaultPartition] New Members : 0 ([])
> 13:23:58,442 INFO  [DefaultPartition] All Members : 1 ([127.0.0.2:1099])
> 13:23:58,581 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|2] [127.0.0.2:42088]
> 13:23:58,620 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|2] [127.0.0.2:42088]
> 13:24:00,260 WARN  [GMS] 127.0.0.2:42088 failed to collect all ACKs (1) 
> for mcasted view [127.0.0.2:42088|2] [127.0.0.2:42088] after 2000ms, 
> missing ACKs from [127.0.0.2:42088] (received=[]), 
> local_addr=127.0.0.2:42088
> 13:24:00,661 INFO  [MessagingPostOffice] JBoss Messaging failover completed
> 13:24:00,662 INFO  [GroupMember] Dead members: 1 ([127.0.0.1:40089])
> 13:24:00,662 INFO  [GroupMember] All Members : 1 ([127.0.0.2:42088])
> 4) At some point the suspected node realizes it is suspected and the 4 
> UDP channels decide to reconnect, two at about the same time and the 
> other two w/in 55 ms of the first two:
> 13:24:39,294 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,295 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,315 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,339 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,359 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,360 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,380 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 5) This is where things break down.  It looks like one of the 4 channels 
> is able to get a local_addr, but the others get null. Perhaps a 
> concurrency bug in Configurator.startProtocolStack? (Note the first 2 
> lines below have to do with the independent TCP channel used by JBM; I 
> post them for completeness.)
> 13:24:39,568 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:39,959 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:40,833 WARN  [GMS]
> 13:24:40,834 WARN  [GMS]
> 13:24:41,362 INFO  [STDOUT]
> ---------------------------------------------------------
> GMS: address is 127.0.0.1:56000 (cluster=DefaultPartition-SFSBCache)
> ---------------------------------------------------------
> 13:24:41,362 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,488 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|3] [127.0.0.2:42088, 127.0.0.1:56000]
> 13:24:41,564 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,564 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,927 INFO  [LegacyStateTransferIntegrator] Using version 4096
> 13:24:45,941 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
> 13:24:45,993 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:7900, 127.0.0.1:7900]
> 13:24:45,995 WARN  [GMS] merge was supposed to be cancelled at merge 
> participant 127.0.0.1:7900 (merge_id=[127.0.0.1:7900|1246037080987]), 
> but it is not since merge ids do not match
> 13:24:46,029 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
> 13:24:46,029 WARN  [GMS] resume([127.0.0.1:40089|1246037080833]) does 
> not match null
> 6) Thereafter, there is continual looping of the CloserThread as it 
> tries to connect a channel, fails due to local_addr == null, waits 1 sec 
> and tries again, which goes on for hours:
> 13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> As I said, I suspect a concurrency issue that's resulting in one channel 
> getting a local_addr but thereafter others with the same shared 
> transport get null.
> Hmm, just noticed: the looping in #6 above repeats every 30 secs, not 
> every second. Which is the timeout in JChannel.startStack() :
> /* Wait LOCAL_ADDR_TIMEOUT milliseconds for local_addr to have a 
> non-null value (set by SET_LOCAL_ADDRESS) */
> local_addr=local_addr_promise.getResult(LOCAL_ADDR_TIMEOUT);
> if(local_addr == null) {
>      log.fatal("local_addr is null; cannot connect");
>      throw new ChannelException("local_addr is null");
> }
> So, seems the recurring problem is local_addr_promise isn't getting set, 
> not that it is getting set, but with a null value. *However* the *first* 
> set of FATAL logging occurs just a couple seconds after GMS logs it is 
> going to reconnect. So that first issue where local_addr == null is not 
> due to a timeout.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 19:34:51 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Wed, 1 Jul 2009 19:34:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1126790880.1246491291503.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474526#action_12474526 ] 

Richard Kennard commented on JBMETA-208:
----------------------------------------

Thank you all for the time and thought you have put into this. I think everybody's position is very reasonable. In particular, I understand...

"When a JAR is deployed, we first look whether there is an ejb-jar.xml. And if it's there we can tell by its version which EJB version this deployment is. And if it's EJB2 then does it make sense to look into each class in the JAR to make sure there are no EJB3 annotations? Because this is what you are asking for. It's rather expensive performance-wise."

At the same time, though, I would counsel that "the deployment should have been completely skipped from the EJB3 processing", without any warning, is rather dangerous. Even though the EJB 3.0 spec might mandate "all EJB deployment descriptors must indicate the ejb-jar schema by using the Java EE namespace" plenty of examples and tutorials on the Web, for reasons of brevity or simply laziness, omit it. For example:

http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html

You can fix the JBoss ones, but not all the third-party ones. If I may humbly suggest a solution:

1. Scan the ejb-jar.xml
2. If it contains a DTD, treat it as EJB 2.x (or 1.x) and don't scan for annotations
3. If it contains a namespace, treat it as EJB 3.x (or above) and scan for annotations
4. If it contains neither a DTD nor a namespace, display a warning that you are entering 'compatibility mode' where you both process the ejb-jar.xml and scan for annotations (at the expense of reduced startup time). The warning should advise the developer 'either add a DTD or a namespace to avoid this warning'

In some ways this is more accurate, because if there is no DTD or namespace you really can't say what version it is.

Regards,

Richard.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <ejb-jar version="3.0"
>     xmlns="http://java.sun.com/xml/ns/javaee"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

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

        


From jira-events at lists.jboss.org  Wed Jul  1 23:56:51 2009
From: jira-events at lists.jboss.org (deckrider deckrider (JIRA))
Date: Wed, 1 Jul 2009 23:56:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-1121) Client
 SocketFactory should be configurable by InvokerLocator
In-Reply-To: <31741702.1239943414266.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <407884410.1246507011505.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBREM-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474528#action_12474528 ] 

deckrider deckrider commented on JBREM-1121:
--------------------------------------------

I'm trying to understand how this new mechanism works.  It seems that adding org.jboss.remoting.serverAuthMode=false" to the EJB3 InvokerLocator.

Before remoting 2.2.3 I was using socketFactoryClassName=some.package.MySocketFactory as per http://www.jboss.org/index.html?module=bb&op=viewtopic&t=153111 but replacing that with serverAuthMode=false isn't working.

I also tried useAllParams=true (as per the docs) but that didn't seem to help either.  And I'm not sure what do do about configOverridesLocator or whether thats having any effect.

> Client SocketFactory should be configurable by InvokerLocator
> -------------------------------------------------------------
>
>                 Key: JBREM-1121
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1121
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.2.SP11, 2.5.1 (Flounder)
>            Reporter: Ron Sigal
>            Assignee: Ron Sigal
>             Fix For: 2.2.3, 2.5.2 (Flounder)
>
>
> org.jboss.remoting.RemoteClientInvoker, which creates the client invoker's SocketFactory, uses only the parameters passed in the configuration map (except for looking in the InvokerLocator for org.jboss.remoting.SOCKET_FACTORY_CLASS_NAME (actual value "socketFactoryClassName"), which was introduced in JBREM-1014 "Support injection of socket factory class name into AbstractInvoker").  There should be a configurable option to use all parameters from the InvokerLocator.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 02:46:51 2009
From: jira-events at lists.jboss.org (Colin Mondesir (JIRA))
Date: Thu, 2 Jul 2009 02:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-1139) Modify PortUtil to
 allow a
 configurable range for MIN_UNPRIVILEGED_PORT and MAX_LEGAL_PORT.
Message-ID: <215395097.1246517211483.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Modify PortUtil to allow a configurable range for MIN_UNPRIVILEGED_PORT and MAX_LEGAL_PORT.
-------------------------------------------------------------------------------------------

                 Key: JBREM-1139
                 URL: https://jira.jboss.org/jira/browse/JBREM-1139
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.2.SP8
            Reporter: Colin Mondesir


PortUtil could be improved to read the port range configuration.
This is straightforward and no side effect is expected.  However,
PortUtil and its callers will need some refactoring as it is just a
static utility classes currently.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 03:46:03 2009
From: jira-events at lists.jboss.org (francesco dicarlo (JIRA))
Date: Thu, 2 Jul 2009 03:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (BPEL-306) Variable Instances
 translation
 funcionality(From MessageValue to simple types like String,Integer,Long)
Message-ID: <2123265903.1246520763456.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Variable Instances translation funcionality(From MessageValue to simple types like String,Integer,Long)
-------------------------------------------------------------------------------------------------------

                 Key: BPEL-306
                 URL: https://jira.jboss.org/jira/browse/BPEL-306
             Project: JBoss jBPM BPEL
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Engine
    Affects Versions: jBPM BPEL 1.1.1
         Environment: Jboss 4.2.3.GA
JBPM-BPEL 1.1.1
            Reporter: francesco dicarlo
            Assignee: Alejandro Guizar


Would be good to have a functionality (i.e. a Translator) to automatically translate VariableInstance that in JBPM-BPEL are of type MessageValue into the simple type that were defined in the workflow.

The use of this code \\Map varsMap=instance.getContextInstance().getVariables();\\ returns a Map with key the name of the variable but with value a type MessageValue that can't be translated automatically for all the workflow because rely on workflow implementation and design.







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

        


From jira-events at lists.jboss.org  Thu Jul  2 03:47:53 2009
From: jira-events at lists.jboss.org (francesco dicarlo (JIRA))
Date: Thu, 2 Jul 2009 03:47:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-306) Variable Instances
 translation
 funcionality(From MessageValue to simple types like String,Integer,Long)
In-Reply-To: <2123265903.1246520763456.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1168253862.1246520873174.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/BPEL-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

francesco dicarlo updated BPEL-306:
-----------------------------------

    Description: 
Would be good to have a functionality (i.e. a Translator) to automatically translate VariableInstance that in JBPM-BPEL are of type MessageValue into the simple type that were defined in the workflow.

The use of this code \\Map varsMap=instance.getContextInstance().getVariables();\\ returns a Map with key the name of the variable but with value a type MessageValue that can't be translated automatically for all the workflow because relies on workflow implementation and design.







  was:
Would be good to have a functionality (i.e. a Translator) to automatically translate VariableInstance that in JBPM-BPEL are of type MessageValue into the simple type that were defined in the workflow.

The use of this code \\Map varsMap=instance.getContextInstance().getVariables();\\ returns a Map with key the name of the variable but with value a type MessageValue that can't be translated automatically for all the workflow because rely on workflow implementation and design.







         Labels: bpel jbpm-bpel   (was: )


> Variable Instances translation funcionality(From MessageValue to simple types like String,Integer,Long)
> -------------------------------------------------------------------------------------------------------
>
>                 Key: BPEL-306
>                 URL: https://jira.jboss.org/jira/browse/BPEL-306
>             Project: JBoss jBPM BPEL
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1.1
>         Environment: Jboss 4.2.3.GA
> JBPM-BPEL 1.1.1
>            Reporter: francesco dicarlo
>            Assignee: Alejandro Guizar
>
> Would be good to have a functionality (i.e. a Translator) to automatically translate VariableInstance that in JBPM-BPEL are of type MessageValue into the simple type that were defined in the workflow.
> The use of this code \\Map varsMap=instance.getContextInstance().getVariables();\\ returns a Map with key the name of the variable but with value a type MessageValue that can't be translated automatically for all the workflow because relies on workflow implementation and design.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 05:43:52 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 2 Jul 2009 05:43:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7029) Test
 org.jboss.test.profileservice.test.PlatformMBeanUnitTestCase(profileservice).testThreadMXBean
 fails on JDK6
In-Reply-To: <9161934.1245234836800.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1856092146.1246527832056.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber reassigned JBAS-7029:
-----------------------------------------

    Assignee: Emanuel Muckenhuber  (was: Shelly McGowan)


> Test org.jboss.test.profileservice.test.PlatformMBeanUnitTestCase(profileservice).testThreadMXBean fails on JDK6
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7029
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7029
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows and Linux 
> JDK6
>            Reporter: Pavel Slavicek
>            Assignee: Emanuel Muckenhuber
>
> Test org.jboss.test.profileservice.test.PlatformMBeanUnitTestCase(profileservice).testThreadMXBean fails on JDK6 on line 
>       Set<ManagedOperation> ops = mo.getOperations();
>       log.debug(ops);
>       assertEquals("Ops count is 8", 8, ops.size());
> JDK6 contains JMX 1.4 and ThreadMXBean has 11 operations.
> Test log:
> junit.framework.AssertionFailedError: Ops count is 8 expected:&lt;8&gt; but was:&lt;11&gt;

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

        


From jira-events at lists.jboss.org  Thu Jul  2 07:17:51 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 2 Jul 2009 07:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-77)
 ClassFile.renameClass(s) is not
 processing the LocalVariableAttributes
In-Reply-To: <16184693.1238601682880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1994600823.1246533471654.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-77.
----------------------------------

    Fix Version/s: 3.11.0.GA
       Resolution: Done


fixed this bug.

> ClassFile.renameClass(s) is not processing the LocalVariableAttributes
> ----------------------------------------------------------------------
>
>                 Key: JASSIST-77
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-77
>             Project: Javassist
>          Issue Type: Bug
>            Reporter: Adrian Brock
>            Assignee: Shigeru Chiba
>             Fix For: 3.11.0.GA
>
>
> ClassFile.renameClass(s) is not changing the descriptor indexes for LocalVariableAttributes.
> This means the types of local variables are not getting updated.
> See the forum thread for an example.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 07:52:51 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Thu, 2 Jul 2009 07:52:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1007) Flush: change
 signature of JChannel#startFlush to include checked exception
Message-ID: <2067196155.1246535571473.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Flush: change signature of JChannel#startFlush to include checked exception
---------------------------------------------------------------------------

                 Key: JGRP-1007
                 URL: https://jira.jboss.org/jira/browse/JGRP-1007
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.6, 2.8
            Reporter: Vladimir Blagojevic
            Assignee: Vladimir Blagojevic
             Fix For: 3.0


We have to change signature of startFlush method to include checked exceptions in its signature. We have previously relied on boolean return value of startFlush to get information about success of startFlush method invocation. This approach has been proven to be insufficient, particularly in the light of dealing with [JGRP-985]. We need to discriminate various reasons why startFlush failed, i.e due flush collision, missing response from flush member and so on. Therefore, starting with release 3.0 startFlush method will be void and will throw checked exceptions.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 07:59:04 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 2 Jul 2009 07:59:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1861) Upgrade
 microcontainer to 2.0.8.GA
Message-ID: <2037967472.1246535944178.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade microcontainer to 2.0.8.GA
----------------------------------

                 Key: EJBTHREE-1861
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1861
             Project: EJB 3.0
          Issue Type: Thirdparty Change
    Affects Versions: 1.1.8
            Reporter: jaikiran pai
            Assignee: jaikiran pai


In order to be able to use the @DisableAOP feature in MC, we need to upgrade to this latest version of MC. 

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

        


From jira-events at lists.jboss.org  Thu Jul  2 08:10:51 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Thu, 2 Jul 2009 08:10:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-985) Flush and join
 problems during constant node failures and constant joins
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1205450929.1246536651451.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Blagojevic resolved JGRP-985.
--------------------------------------

    Resolution: Won't Fix


While we acknowledge that this issue is possible we are confident that it is highly unlikely to occur in normal range of operations. We have added a unit test FlushWithChannelJoinsAndFailuresTest in an attempt to capture the scenario you describe while we have concluded that we can deal with similar cases a bit better in the upcoming releases. Therefore, we have opened [JGRP-1007] as a continuation of flush issues first discovered in this case.   

> Flush and join problems during constant node failures and constant joins
> ------------------------------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 08:14:52 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Thu, 2 Jul 2009 08:14:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <105167905.1246536892464.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474602#action_12474602 ] 

Victor N commented on JGRP-1003:
--------------------------------

I will check how it works now.
By the way, I would recommend to set use_send_queues="true" in the default tcp.xml in JGroups sources/examples!

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

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

        


From jira-events at lists.jboss.org  Thu Jul  2 08:18:51 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 2 Jul 2009 08:18:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-215) Allow for
 configuration of transaction-retry
Message-ID: <950768065.1246537131938.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Allow for configuration of transaction-retry
--------------------------------------------

                 Key: JBMETA-215
                 URL: https://jira.jboss.org/jira/browse/JBMETA-215
             Project: JBoss Metadata
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf
             Fix For: 1.0.2.Beta2, 2.0.0.CR1


The @TransactionRetry annotation must have an equivalent configuration option in descriptors.

@TransactionRetry(numRetries=4, waitTime=1, waitTimeUnit=TimeUnit.SECONDS) 

<assembly-descriptor>
  <transaction-retry>
    <!-- bindings as per spec -->
    <method>
      <ejb-name>*</ejb-name>
      <method-name>...</method-name>
    </method>
    ...
    <num-retries>4</num-retries>
    <wait-time>1</wait-time>
    <wait-time-unit>SECONDS</wait-time-unit>
  </transaction-retry>
</assembly-descriptor>

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

        


From jira-events at lists.jboss.org  Thu Jul  2 08:22:52 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 2 Jul 2009 08:22:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1499536855.1246537372929.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474608#action_12474608 ] 

Bela Ban commented on JGRP-1003:
--------------------------------

set use_send_queue="true" in all TCP configs

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

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

        


From jira-events at lists.jboss.org  Thu Jul  2 08:22:52 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Thu, 2 Jul 2009 08:22:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMICROCONT-446)
 bean-deployer xsds don't contain web references
In-Reply-To: <12930376.1245605276537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1977909108.1246537372718.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMICROCONT-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474607#action_12474607 ] 

Wolfgang Knauf commented on JBMICROCONT-446:
--------------------------------------------

Hi David,

after doing a bit of google, I agree with you: it seems that the parser should search for the included file in the same location as the current XSD if no full URI is specified.
A short test reveals: this seems to work for jboss_5_1.xsd and jboss-common_5_1.xsd.

The only possible problem where this might fail is when you add "bean-deployer_2_0.xsd" to your project and don't add the included "jboss-beans-common_2_0.xsd". Then Eclipse cannot find the included XSD (a similar thing happened to me some time ago while checking another validation error in jboss_5_1.xsd). 

Hopefully, the XSD files will be added to the JBoss website so that I can give them a try.

So, if you don't want to change it, you can close this issue. But I would prefer full web URIs ;-).

> bean-deployer xsds don't contain web references
> -----------------------------------------------
>
>                 Key: JBMICROCONT-446
>                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-446
>             Project: JBoss Microcontainer
>          Issue Type: Bug
>            Reporter: Wolfgang Knauf
>            Assignee: Kabir Khan
>
> bean-deployer_2_0.xsd:
>    <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">
> =>should point. 
>    <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">
> The comment for a sample instance should also contain a schema location attribute:
>          <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xmlns="urn:jboss:bean-deployer:2.0"
>             xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">
> ==================
> bean-deployer_1_0.xsd:
> The comment for a sample instance should point to the web schema location:
>          <deployment
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
>             xmlns="urn:jboss:bean-deployer">
> =================
> policy_1_0.xsd:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
> should be:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>
> =================
> bean-deployer_2_0.xsd raises validation errors in Eclipse:
> -rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
> -src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
> According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426 ), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 08:22:52 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Thu, 2 Jul 2009 08:22:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-985) Flush and join
 problems during constant node failures and constant joins
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1996112044.1246537372263.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Blagojevic updated JGRP-985:
-------------------------------------

    Comment: was deleted


> Flush and join problems during constant node failures and constant joins
> ------------------------------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 08:22:52 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Thu, 2 Jul 2009 08:22:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-985) Flush and join
 problems during constant node failures and constant joins
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2084107928.1246537372552.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474606#action_12474606 ] 

Vladimir Blagojevic commented on JGRP-985:
------------------------------------------

While we acknowledge that this issue is possible we are confident that it is highly unlikely to occur in normal range of operations. We have added a unit test FlushWithChannelJoinsAndFailuresTest in an attempt to capture the scenario you describe. We have concluded that we can deal with similar cases a bit better in the upcoming releases. Therefore, we have opened [JGRP-1007] as a continuation of flush issues first discovered in this case. 

> Flush and join problems during constant node failures and constant joins
> ------------------------------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 08:44:51 2009
From: jira-events at lists.jboss.org (Daniel Cullender (JIRA))
Date: Thu, 2 Jul 2009 08:44:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1676) Jboss
	Messaging deadlock
Message-ID: <317741887.1246538691801.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Jboss Messaging deadlock
------------------------

                 Key: JBMESSAGING-1676
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1676
             Project: JBoss Messaging
          Issue Type: Bug
          Components: AS Integration
    Affects Versions: 1.4.3.GA
         Environment: Version:Linux 2.6.18-53.el5
Description:Linux Operating System
Traits
OS Name: Linux
OS Version: 2.6.18-53.el5
Architecture: i386
Distribution Name: CentOS
Distribution Version: release 5 (Final)
            Reporter: Daniel Cullender
            Assignee: Tim Fox


Under high concurrent load it appears that jboss messaging gets stuck in the Hashmap.put method which causes the threads to deadlock which in turn causes transaction timeouts.

We have several mdb's which have max session sizes of 150, we have max strict pool size of 150 and the jboss thread pool size of 50.

Recently upgraded from jboss AS 4 MQ series to jboss 5 AS with jboss messaging 1.4.3.GA, with JbossMQ  this problem did not occur.

The stack trace of the problem is as follows :

Thread: WorkManager(2)-50 : priority:5, demon:true, threadId:147,
threadState:RUNNABLE
java.util.HashMap.put(HashMap.java:374)
java.util.HashSet.add(HashSet.java:200)
org.jboss.jms.client.state.HierarchicalStateSupport.(HierarchicalStateSupport.java:63)
org.jboss.jms.client.state.ProducerState.(ProducerState.java:68)
org.jboss.jms.client.container.StateCreationAspect.handleCreateProducerDelegate(StateCreationAspect.java:180)
org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateProducerDelegate_30485827.invoke(StateCreationAspect_z_handleCreateProducerDelegate_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.jms.client.delegate.ClientSessionDelegate.createProducerDelegate(ClientSessionDelegate.java)
org.jboss.jms.client.JBossSession.createProducer(JBossSession.java:209)
qut.common.dao.JmsDao.publishMessage(JmsDao.java:66)
qut.common.dao.JmsDao.publish(JmsDao.java:104)
qut.order.manager.OrderManagerMBean.publish(OrderManagerMBean.java:156)
qut.order.manager.OrderManagerMBean.process(OrderManagerMBean.java:98)
sun.reflect.GeneratedMethodAccessor354.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:451)
org.jboss.ejb3.service.ServiceMBeanDelegate.invoke(ServiceMBeanDelegate.java:215)
org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
$Proxy1543.process(Unknown Source)
qut.order.mdb.OrderManagerTradingDataMDBean.onMessage(OrderManagerTradingDataMDBean.java:64)
sun.reflect.GeneratedMethodAccessor353.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor$InvocationContext.proceed(InvocationContextInterceptor.java:138)
qut.common.interceptor.ConcurrencyInterceptor.myInterceptor(ConcurrencyInterceptor.java:46)
sun.reflect.GeneratedMethodAccessor320.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:83)
org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:70)
org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:59)
org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:80)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:282)
org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:270)
org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:140)
$Proxy389.onMessage(Unknown Source)
org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:178)
org.jboss.jms.client.container.ClientConsumer.callOnMessageStatic(ClientConsumer.java:160)
org.jboss.jms.client.container.SessionAspect.handleRun(SessionAspect.java:831)
org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleRun_30485827.invoke(SessionAspect_z_handleRun_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.jms.client.delegate.ClientSessionDelegate.run(ClientSessionDelegate.java)
org.jboss.jms.client.JBossSession.run(JBossSession.java:199)
org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:234)
org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205)
org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
java.lang.Thread.run(Thread.java:619)

Locked synchronizers : 
- locked <0x535d1e> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

Thread: WorkManager(2)-70 : priority:5, demon:true, threadId:168,
threadState:RUNNABLE
java.util.HashMap.put(HashMap.java:374)
java.util.HashSet.add(HashSet.java:200)
org.jboss.jms.client.state.HierarchicalStateSupport.(HierarchicalStateSupport.java:63)
org.jboss.jms.client.state.ProducerState.(ProducerState.java:68)
org.jboss.jms.client.container.StateCreationAspect.handleCreateProducerDelegate(StateCreationAspect.java:180)
org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateProducerDelegate_30485827.invoke(StateCreationAspect_z_handleCreateProducerDelegate_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.jms.client.delegate.ClientSessionDelegate.createProducerDelegate(ClientSessionDelegate.java)
org.jboss.jms.client.JBossSession.createProducer(JBossSession.java:209)
qut.common.dao.JmsDao.publishMessage(JmsDao.java:66)
qut.common.dao.JmsDao.publish(JmsDao.java:104)
qut.order.manager.OrderManagerMBean.publish(OrderManagerMBean.java:156)
qut.order.manager.OrderManagerMBean.process(OrderManagerMBean.java:98)
sun.reflect.GeneratedMethodAccessor354.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:451)
org.jboss.ejb3.service.ServiceMBeanDelegate.invoke(ServiceMBeanDelegate.java:215)
org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
$Proxy1384.process(Unknown Source)
qut.order.mdb.OrderManagerTradingDataMDBean.onMessage(OrderManagerTradingDataMDBean.java:64)
sun.reflect.GeneratedMethodAccessor353.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor$InvocationContext.proceed(InvocationContextInterceptor.java:138)
qut.common.interceptor.ConcurrencyInterceptor.myInterceptor(ConcurrencyInterceptor.java:46)
sun.reflect.GeneratedMethodAccessor320.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:83)
org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:70)
org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:59)
org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:80)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:282)
org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:270)
org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:140)
$Proxy389.onMessage(Unknown Source)
org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:178)
org.jboss.jms.client.container.ClientConsumer.callOnMessageStatic(ClientConsumer.java:160)
org.jboss.jms.client.container.SessionAspect.handleRun(SessionAspect.java:831)
org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleRun_30485827.invoke(SessionAspect_z_handleRun_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.jms.client.delegate.ClientSessionDelegate.run(ClientSessionDelegate.java)
org.jboss.jms.client.JBossSession.run(JBossSession.java:199)
org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:234)
org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205)
org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
java.lang.Thread.run(Thread.java:619)

Locked synchronizers : 
- locked <0x18827b6> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)





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

        


From jira-events at lists.jboss.org  Thu Jul  2 09:29:51 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 2 Jul 2009 09:29:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1008) PING: remove
 functionality for accessing GossipRouters and static lists
Message-ID: <524579444.1246541391446.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

PING: remove functionality for accessing GossipRouters and static lists
-----------------------------------------------------------------------

                 Key: JGRP-1008
                 URL: https://jira.jboss.org/jira/browse/JGRP-1008
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.0


If initial_hosts is used, switch to TCPPING instead. If gossip_hosts is used, use TCPGOSSIP instead.

We can remove this (duplicate) functionality

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

        


From jira-events at lists.jboss.org  Thu Jul  2 09:35:51 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 2 Jul 2009 09:35:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1008) PING: remove
 functionality for accessing GossipRouters and static lists
In-Reply-To: <524579444.1246541391446.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <736773665.1246541751591.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1008:
---------------------------

    Fix Version/s: 2.8
                       (was: 3.0)


> PING: remove functionality for accessing GossipRouters and static lists
> -----------------------------------------------------------------------
>
>                 Key: JGRP-1008
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1008
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> If initial_hosts is used, switch to TCPPING instead. If gossip_hosts is used, use TCPGOSSIP instead.
> We can remove this (duplicate) functionality

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

        


From jira-events at lists.jboss.org  Thu Jul  2 09:40:51 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 2 Jul 2009 09:40:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1008) PING: remove
 functionality for accessing GossipRouters and static lists
In-Reply-To: <524579444.1246541391446.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1545988388.1246542051547.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1008.
----------------------------

    Resolution: Done


> PING: remove functionality for accessing GossipRouters and static lists
> -----------------------------------------------------------------------
>
>                 Key: JGRP-1008
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1008
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> If initial_hosts is used, switch to TCPPING instead. If gossip_hosts is used, use TCPGOSSIP instead.
> We can remove this (duplicate) functionality

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

        


From jira-events at lists.jboss.org  Thu Jul  2 09:57:51 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 2 Jul 2009 09:57:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMICROCONT-446)
 bean-deployer xsds don't contain web references
In-Reply-To: <12930376.1245605276537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <715563072.1246543071923.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMICROCONT-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474632#action_12474632 ] 

David Lloyd commented on JBMICROCONT-446:
-----------------------------------------

Both of the XSD files are distributed together in the MC maven artifact and other distributions, so it should be easy enough to grab both files by hand at worst (with IDEA it's never had a problem finding them both).

I think all of the problems in the ticket have been addressed, but since Kabir grabbed this ticket, it's ultimately up to him whether to close it. :-)

> bean-deployer xsds don't contain web references
> -----------------------------------------------
>
>                 Key: JBMICROCONT-446
>                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-446
>             Project: JBoss Microcontainer
>          Issue Type: Bug
>            Reporter: Wolfgang Knauf
>            Assignee: Kabir Khan
>
> bean-deployer_2_0.xsd:
>    <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">
> =>should point. 
>    <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">
> The comment for a sample instance should also contain a schema location attribute:
>          <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xmlns="urn:jboss:bean-deployer:2.0"
>             xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">
> ==================
> bean-deployer_1_0.xsd:
> The comment for a sample instance should point to the web schema location:
>          <deployment
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
>             xmlns="urn:jboss:bean-deployer">
> =================
> policy_1_0.xsd:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
> should be:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>
> =================
> bean-deployer_2_0.xsd raises validation errors in Eclipse:
> -rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
> -src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
> According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426 ), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 10:53:51 2009
From: jira-events at lists.jboss.org (Mike Conner (JIRA))
Date: Thu, 2 Jul 2009 10:53:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7071) use-try-lock option
 in data source configuration files is ignored
In-Reply-To: <329869123.1246546191859.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1409636642.1246546431897.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Conner updated JBAS-7071:
------------------------------

    Priority: Minor  (was: Major)


> use-try-lock option in data source configuration files is ignored
> -----------------------------------------------------------------
>
>                 Key: JBAS-7071
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7071
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows XP Professional V2002, service pack 3
>            Reporter: Mike Conner
>            Assignee: Jesper Pedersen
>            Priority: Minor
>
> (FYI  your "READ THIS BEFORE ENTERING NEW REPORTS" points to a  "You caught us doing a little maintenance..." page, so pardon me if I missed something in procedure. )
> The data source configuration property "use-try-lock" is effectively ignored.
> This is because the value is defined in configuration as a long, but the object that is actually set on  an
> org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory  extends 
>    org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnectionFactory
> This class defines it as taking an int, not a long:
>    public void setUseTryLock(int useTryLock)
> As such, reflection in ManagedConnectionFactoryDeployment.setManagedConnectionFactoryAttribute() does not find the method and simply logs it at a trace level, so the value never gets set.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 10:49:51 2009
From: jira-events at lists.jboss.org (Mike Conner (JIRA))
Date: Thu, 2 Jul 2009 10:49:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7071) use-try-lock option
 in data source configuration files is ignored
Message-ID: <329869123.1246546191859.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

use-try-lock option in data source configuration files is ignored
-----------------------------------------------------------------

                 Key: JBAS-7071
                 URL: https://jira.jboss.org/jira/browse/JBAS-7071
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA service
    Affects Versions: JBossAS-5.1.0.GA
         Environment: Windows XP Professional V2002, service pack 3
            Reporter: Mike Conner
            Assignee: Jesper Pedersen


(FYI  your "READ THIS BEFORE ENTERING NEW REPORTS" points to a  "You caught us doing a little maintenance..." page, so pardon me if I missed something in procedure. )

The data source configuration property "use-try-lock" is effectively ignored.
This is because the value is defined in configuration as a long, but the object that is actually set on  an

org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory  extends 
   org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnectionFactory

This class defines it as taking an int, not a long:

   public void setUseTryLock(int useTryLock)

As such, reflection in ManagedConnectionFactoryDeployment.setManagedConnectionFactoryAttribute() does not find the method and simply logs it at a trace level, so the value never gets set.






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

        


From jira-events at lists.jboss.org  Thu Jul  2 11:04:51 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 2 Jul 2009 11:04:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7072) Don't write a URL
 for host 0.0.0.0 in jnp-service.url
Message-ID: <15437469.1246547091499.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Don't write a URL for host 0.0.0.0 in jnp-service.url
-----------------------------------------------------

                 Key: JBAS-7072
                 URL: https://jira.jboss.org/jira/browse/JBAS-7072
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Management services, Naming
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: JBossAS-5.2.0.Beta1


See JOPR-254 for an explanation of the issue. This issue is to ensure NamingServiceURLWriter writes the correct URL.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 11:12:51 2009
From: jira-events at lists.jboss.org (Mike Conner (JIRA))
Date: Thu, 2 Jul 2009 11:12:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7071) use-try-lock
 option in data source configuration files is ignored
In-Reply-To: <329869123.1246546191859.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1977140896.1246547571410.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474647#action_12474647 ] 

Mike Conner commented on JBAS-7071:
-----------------------------------

One other thing,  the documentation in the dtd (docs\dtd\jboss-ds_5_0.dtd) states:

<!-- Any configured timeout for internal locks on the resource adapter objects in milli-seconds

     The default is a 60 second timeout
     e.g. 5 minutes
     <use-try-lock>300000</use-try-lock>
-->

However, the code in BaseWrapperManagedConnection is actually is doing:

      try
      {
         if (lock.tryLock(tryLock, TimeUnit.SECONDS) == false)
            throw new SQLException("Unable to obtain lock in " + tryLock + " seconds: " + this);
      }

That is, the value represents seconds, not milliseconds.






> use-try-lock option in data source configuration files is ignored
> -----------------------------------------------------------------
>
>                 Key: JBAS-7071
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7071
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows XP Professional V2002, service pack 3
>            Reporter: Mike Conner
>            Assignee: Jesper Pedersen
>            Priority: Minor
>
> (FYI  your "READ THIS BEFORE ENTERING NEW REPORTS" points to a  "You caught us doing a little maintenance..." page, so pardon me if I missed something in procedure. )
> The data source configuration property "use-try-lock" is effectively ignored.
> This is because the value is defined in configuration as a long, but the object that is actually set on  an
> org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory  extends 
>    org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnectionFactory
> This class defines it as taking an int, not a long:
>    public void setUseTryLock(int useTryLock)
> As such, reflection in ManagedConnectionFactoryDeployment.setManagedConnectionFactoryAttribute() does not find the method and simply logs it at a trace level, so the value never gets set.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 11:32:51 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 2 Jul 2009 11:32:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-86) Make concurrent
 calls to getRefClasses() safe.
Message-ID: <119743334.1246548771405.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Make concurrent calls to getRefClasses() safe.
----------------------------------------------

                 Key: JASSIST-86
                 URL: https://jira.jboss.org/jira/browse/JASSIST-86
             Project: Javassist
          Issue Type: Bug
    Affects Versions: 3.10.0.GA
            Reporter: Shigeru Chiba
            Assignee: Shigeru Chiba


There is a race condition when getRefClasses is called twice concurrently on
the same class - one of the chains in HashMap for collision resolution can become
cyclic, i.e. an infinitely long list, causing iteration on the list to enter an
infinite loop.

On a CtClass ct, the call path leading to the problem is:

ct.getRefClasses() -> ct.renameClass() (it's a fake renameClass(), which does
not rename anything) -> ct.constPool.renameClass()

One can thus have concurrent calls to ct.constPool.renameClass(); a constPool
then recreates the internal HashMap, i.e. reinserts again all elements into
cp.classes (not a temporary map), so we have concurrent accesses to this map.
In particular, since there can be a collision (as happened for me), the
collision chain could become cyclic.

This was found through remote debugging on a concurrent program using Javassist
(attaching after a series of run-client invocations ended in a crash). It was a
real-world program, not a client written on purpose to show this.
This patch solves the problem well, and was tested in a configuration which caused a
lot of crashes and stopped causing any.

Lots of better fixes to this could be thought, but they're more invasive.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 11:34:51 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 2 Jul 2009 11:34:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JASSIST-86) Make concurrent
 calls to getRefClasses() safe.
In-Reply-To: <119743334.1246548771405.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <38852961.1246548891729.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba updated JASSIST-86:
---------------------------------

    Attachment: fix-javassist-concurrency


patch file

> Make concurrent calls to getRefClasses() safe.
> ----------------------------------------------
>
>                 Key: JASSIST-86
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-86
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>            Reporter: Shigeru Chiba
>            Assignee: Shigeru Chiba
>         Attachments: fix-javassist-concurrency
>
>
> There is a race condition when getRefClasses is called twice concurrently on
> the same class - one of the chains in HashMap for collision resolution can become
> cyclic, i.e. an infinitely long list, causing iteration on the list to enter an
> infinite loop.
> On a CtClass ct, the call path leading to the problem is:
> ct.getRefClasses() -> ct.renameClass() (it's a fake renameClass(), which does
> not rename anything) -> ct.constPool.renameClass()
> One can thus have concurrent calls to ct.constPool.renameClass(); a constPool
> then recreates the internal HashMap, i.e. reinserts again all elements into
> cp.classes (not a temporary map), so we have concurrent accesses to this map.
> In particular, since there can be a collision (as happened for me), the
> collision chain could become cyclic.
> This was found through remote debugging on a concurrent program using Javassist
> (attaching after a series of run-client invocations ended in a crash). It was a
> real-world program, not a client written on purpose to show this.
> This patch solves the problem well, and was tested in a configuration which caused a
> lot of crashes and stopped causing any.
> Lots of better fixes to this could be thought, but they're more invasive.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 11:43:51 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 2 Jul 2009 11:43:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-87) ClassFile.prune()
 makes a constant pool empty.
Message-ID: <150232651.1246549431739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

ClassFile.prune() makes a constant pool empty.
----------------------------------------------

                 Key: JASSIST-87
                 URL: https://jira.jboss.org/jira/browse/JASSIST-87
             Project: Javassist
          Issue Type: Bug
    Affects Versions: 3.10.0.GA
            Reporter: Shigeru Chiba
            Assignee: Shigeru Chiba
         Attachments: fix-javassist-prune

ClassFile.prune calls ConstPool.prune(), which empties the Constant Pool completely.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 11:43:51 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 2 Jul 2009 11:43:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JASSIST-87) ClassFile.prune()
 makes a constant pool empty.
In-Reply-To: <150232651.1246549431739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1980822433.1246549431806.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba updated JASSIST-87:
---------------------------------

    Attachment: fix-javassist-prune


> ClassFile.prune() makes a constant pool empty.
> ----------------------------------------------
>
>                 Key: JASSIST-87
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-87
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>            Reporter: Shigeru Chiba
>            Assignee: Shigeru Chiba
>         Attachments: fix-javassist-prune
>
>
> ClassFile.prune calls ConstPool.prune(), which empties the Constant Pool completely.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 11:45:51 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 2 Jul 2009 11:45:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-86) Make concurrent
 calls to getRefClasses() safe.
In-Reply-To: <119743334.1246548771405.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1269396007.1246549551664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-86.
----------------------------------

    Fix Version/s: 3.11.0.GA
       Resolution: Done


> Make concurrent calls to getRefClasses() safe.
> ----------------------------------------------
>
>                 Key: JASSIST-86
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-86
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>            Reporter: Shigeru Chiba
>            Assignee: Shigeru Chiba
>             Fix For: 3.11.0.GA
>
>         Attachments: fix-javassist-concurrency
>
>
> There is a race condition when getRefClasses is called twice concurrently on
> the same class - one of the chains in HashMap for collision resolution can become
> cyclic, i.e. an infinitely long list, causing iteration on the list to enter an
> infinite loop.
> On a CtClass ct, the call path leading to the problem is:
> ct.getRefClasses() -> ct.renameClass() (it's a fake renameClass(), which does
> not rename anything) -> ct.constPool.renameClass()
> One can thus have concurrent calls to ct.constPool.renameClass(); a constPool
> then recreates the internal HashMap, i.e. reinserts again all elements into
> cp.classes (not a temporary map), so we have concurrent accesses to this map.
> In particular, since there can be a collision (as happened for me), the
> collision chain could become cyclic.
> This was found through remote debugging on a concurrent program using Javassist
> (attaching after a series of run-client invocations ended in a crash). It was a
> real-world program, not a client written on purpose to show this.
> This patch solves the problem well, and was tested in a configuration which caused a
> lot of crashes and stopped causing any.
> Lots of better fixes to this could be thought, but they're more invasive.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 11:51:51 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 2 Jul 2009 11:51:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-87) ClassFile.prune()
 makes a constant pool empty.
In-Reply-To: <150232651.1246549431739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <383067963.1246549911502.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-87.
----------------------------------

    Fix Version/s: 3.11.0.GA
       Resolution: Done


> ClassFile.prune() makes a constant pool empty.
> ----------------------------------------------
>
>                 Key: JASSIST-87
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-87
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>            Reporter: Shigeru Chiba
>            Assignee: Shigeru Chiba
>             Fix For: 3.11.0.GA
>
>         Attachments: fix-javassist-prune
>
>
> ClassFile.prune calls ConstPool.prune(), which empties the Constant Pool completely.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 12:12:04 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Thu, 2 Jul 2009 12:12:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBAS-7073) ValueExpression is not
 working with JBOSS 5.1.0
Message-ID: <1554358156.1246551124037.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert moved JSFUNIT-216 to JBAS-7073:
--------------------------------------------

        Project: JBoss Application Server  (was: JSFUnit)
            Key: JBAS-7073  (was: JSFUNIT-216)
    Component/s: JSF
                     (was: Core)
       Security: Public


> ValueExpression is not working with JBOSS 5.1.0
> -----------------------------------------------
>
>                 Key: JBAS-7073
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7073
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>         Environment: windows environment
>            Reporter: anil kumar
>            Assignee: Stan Silvert
>            Priority: Critical
>
> sample code is here, its giving  /welcomeJSF.jsp(26,12) According to TLD or attribute directive in tag file, attribute title does not accept any expressions
> welcomeJSF.jsp
> <%@page contentType="text/html"%>
> <%@page pageEncoding="UTF-8"%>
>  <%@ page import="javax.el.ValueExpression"  %>
>  <%@ page import="javax.el.ExpressionFactory"  %>
>   <%@ page import ="com.sun.el.ExpressionFactoryImpl"%>
>  
> <%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
> <%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
>    "http://www.w3.org/TR/html4/loose.dtd">
> <%--
>     This file is an entry point for JavaServer Faces application.
> --%>
> <f:view>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
>         <title>JSP Page</title>
>     </head>
>     <body>
>         
>         <%
>           ExpressionFactory el = new ExpressionFactoryImpl();         
>        ValueExpression testExpression =  el.createValueExpression( " Test" ,  new String().getClass()); 
>         %>
>        
>         <h:form>        
>             <h:commandLink title="<%=testExpression%>" id="next" action="#">
>    <h:outputText value="Next Page ?" />
>     </h:commandLink>
>             <h1><h:outputText value="JavaServer Faces" /></h1>
>        
>     </h:form>
>     </body>
> </html>
>  </f:view>

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

       



From jira-events at lists.jboss.org  Thu Jul  2 12:32:51 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Thu, 2 Jul 2009 12:32:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7073) ValueExpression is
 not working with JBOSS 5.1.0
Message-ID: <1711371571.1246552371644.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474661#action_12474661 ] 

Stan Silvert commented on JBAS-7073:
------------------------------------

It's not talking about the ValueExpression.  It's talking about the fact that you used <%=something%>.  This is not allowed for the title attribute.  

> ValueExpression is not working with JBOSS 5.1.0
> -----------------------------------------------
>
>                 Key: JBAS-7073
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7073
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>         Environment: windows environment
>            Reporter: anil kumar
>            Assignee: Stan Silvert
>            Priority: Critical
>
> sample code is here, its giving  /welcomeJSF.jsp(26,12) According to TLD or attribute directive in tag file, attribute title does not accept any expressions
> welcomeJSF.jsp
> <%@page contentType="text/html"%>
> <%@page pageEncoding="UTF-8"%>
>  <%@ page import="javax.el.ValueExpression"  %>
>  <%@ page import="javax.el.ExpressionFactory"  %>
>   <%@ page import ="com.sun.el.ExpressionFactoryImpl"%>
>  
> <%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
> <%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
>    "http://www.w3.org/TR/html4/loose.dtd">
> <%--
>     This file is an entry point for JavaServer Faces application.
> --%>
> <f:view>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
>         <title>JSP Page</title>
>     </head>
>     <body>
>         
>         <%
>           ExpressionFactory el = new ExpressionFactoryImpl();         
>        ValueExpression testExpression =  el.createValueExpression( " Test" ,  new String().getClass()); 
>         %>
>        
>         <h:form>        
>             <h:commandLink title="<%=testExpression%>" id="next" action="#">
>    <h:outputText value="Next Page ?" />
>     </h:commandLink>
>             <h1><h:outputText value="JavaServer Faces" /></h1>
>        
>     </h:form>
>     </body>
> </html>
>  </f:view>

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

       



From jira-events at lists.jboss.org  Thu Jul  2 12:32:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 2 Jul 2009 12:32:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBASPECT-32) Fix dependency
	upon JACC API
Message-ID: <228336563.1246552371423.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Fix dependency upon JACC API
----------------------------

                 Key: JBASPECT-32
                 URL: https://jira.jboss.org/jira/browse/JBASPECT-32
             Project: JBoss Aspects
          Issue Type: Task
          Components: security
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 1.0.1.GA-security 


>From AS Branch_5_x "build" module:
[INFO] [dependency:tree]
[INFO] org.jboss.jbossas:jboss-as-build:pom:5.2.0-SNAPSHOT
[INFO] \- org.jboss.jbossas:jboss-as-aspects:jar:5.2.0-SNAPSHOT:compile
[INFO]    \- org.jboss.aspects:jboss-security-aspects:jar:1.0.0.GA:compile
[INFO]       \- javax.security:jacc:jar:1.0:compil

Instead we need to be defining the dependency upon "org.jboss.javaee:jboss-javaee".

As a result this doesn't make it into the AS dependency tree correctly (though the build places the proper artifact into the distribution/runtime).  Embedded gets the wrong artifact as a result.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 12:34:51 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Thu, 2 Jul 2009 12:34:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7073) ValueExpression is
 not working with JBOSS 5.1.0
Message-ID: <201867251.1246552491436.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert resolved JBAS-7073.
--------------------------------

    Resolution: Rejected


> ValueExpression is not working with JBOSS 5.1.0
> -----------------------------------------------
>
>                 Key: JBAS-7073
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7073
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>         Environment: windows environment
>            Reporter: anil kumar
>            Assignee: Stan Silvert
>            Priority: Critical
>
> sample code is here, its giving  /welcomeJSF.jsp(26,12) According to TLD or attribute directive in tag file, attribute title does not accept any expressions
> welcomeJSF.jsp
> <%@page contentType="text/html"%>
> <%@page pageEncoding="UTF-8"%>
>  <%@ page import="javax.el.ValueExpression"  %>
>  <%@ page import="javax.el.ExpressionFactory"  %>
>   <%@ page import ="com.sun.el.ExpressionFactoryImpl"%>
>  
> <%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
> <%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
>    "http://www.w3.org/TR/html4/loose.dtd">
> <%--
>     This file is an entry point for JavaServer Faces application.
> --%>
> <f:view>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
>         <title>JSP Page</title>
>     </head>
>     <body>
>         
>         <%
>           ExpressionFactory el = new ExpressionFactoryImpl();         
>        ValueExpression testExpression =  el.createValueExpression( " Test" ,  new String().getClass()); 
>         %>
>        
>         <h:form>        
>             <h:commandLink title="<%=testExpression%>" id="next" action="#">
>    <h:outputText value="Next Page ?" />
>     </h:commandLink>
>             <h1><h:outputText value="JavaServer Faces" /></h1>
>        
>     </h:form>
>     </body>
> </html>
>  </f:view>

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

       



From jira-events at lists.jboss.org  Thu Jul  2 14:22:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 2 Jul 2009 14:22:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBASPECT-32) Fix dependency
	upon JACC API
In-Reply-To: <228336563.1246552371423.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <862886610.1246558971583.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBASPECT-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBASPECT-32.
-----------------------------------------

    Resolution: Done


> Fix dependency upon JACC API
> ----------------------------
>
>                 Key: JBASPECT-32
>                 URL: https://jira.jboss.org/jira/browse/JBASPECT-32
>             Project: JBoss Aspects
>          Issue Type: Task
>          Components: security
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.0.1-security 
>
>
> From AS Branch_5_x "build" module:
> [INFO] [dependency:tree]
> [INFO] org.jboss.jbossas:jboss-as-build:pom:5.2.0-SNAPSHOT
> [INFO] \- org.jboss.jbossas:jboss-as-aspects:jar:5.2.0-SNAPSHOT:compile
> [INFO]    \- org.jboss.aspects:jboss-security-aspects:jar:1.0.0.GA:compile
> [INFO]       \- javax.security:jacc:jar:1.0:compil
> Instead we need to be defining the dependency upon "org.jboss.javaee:jboss-javaee".
> As a result this doesn't make it into the AS dependency tree correctly (though the build places the proper artifact into the distribution/runtime).  Embedded gets the wrong artifact as a result.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 14:24:51 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Thu, 2 Jul 2009 14:24:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1862) False WARN
 message if res-type is missing in resource-ref
Message-ID: <455794687.1246559091538.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

False WARN message if res-type is missing in resource-ref
---------------------------------------------------------

                 Key: EJBTHREE-1862
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1862
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: 1.1.7
            Reporter: Wolfgang Knauf
            Priority: Minor


This one was introduced by https://jira.jboss.org/jira/browse/EJBTHREE-1823

I think this warn message is a slight violation of the spec (chapter 16.7.1.3 of EJB3 spec and 5.6.2 of JavaEE5 spec):

"The resource-ref element consists of ... the optional res-type .... The res-type element is optional if an injection target is specified for the
resource; in this case, the res-type defaults to the type of the injection target." 

So, the warning should only be output if no injection target is specified.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 14:36:51 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Thu, 2 Jul 2009 14:36:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1863) res-type in
 resource-ref is not checked
Message-ID: <2026359205.1246559811397.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

res-type in resource-ref is not checked
---------------------------------------

                 Key: EJBTHREE-1863
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1863
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: 1.1.7
            Reporter: Wolfgang Knauf


The "res-type" of the "resource-ref" element in ejb-jar.xml is not verified.

See the attached sample: neither on deploy nor on JNDI lookup, an error is raised for this xml snippet, which contains an invalid res-type:
			<resource-ref>
				<res-ref-name>EnvNameOfSessionContext1</res-ref-name>
 				<res-type>whole.lotta.Crap</res-type>
				<mapped-name>java:comp/EJBContext</mapped-name>
				<injection-target>
					<injection-target-class>de.knauf.resourceref.ResourceRefTestBean</injection-target-class>
					<injection-target-name>sessionContext1</injection-target-name>
			  	</injection-target>
			</resource-ref>

			<resource-ref>
				<res-ref-name>EnvNameOfSessionContext2</res-ref-name>
 				<res-type>whole.lotta.Crap</res-type>
				<mapped-name>java:comp/EJBContext</mapped-name>
			</resource-ref>
The class org.jboss.injection.ResourceHandler.loadXmlResourceRefs almost completely ignores the "res-type" element ;-).

For a "resource-env-ref" element, the "resource-env-ref-type" is validated, though maybe this happens by accident ;-):
Caused by: java.lang.ClassNotFoundException: asdjavax.ejb.SessionContext from BaseClassLoader at 22adfd{...}
	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:448)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClassInternal(Unknown Source)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Unknown Source)
	at org.jboss.injection.ResourceHandler.loadXmlResourceEnvRefs(ResourceHandler.java:217)
	... 73 more

So, I would like a similar check for the "resource-ref" res-type.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 14:38:51 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Thu, 2 Jul 2009 14:38:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1863) res-type in
 resource-ref is not checked
In-Reply-To: <2026359205.1246559811397.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <788044456.1246559931931.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolfgang Knauf updated EJBTHREE-1863:
-------------------------------------

    Attachment: ResourceRef.ear


Sample containing an ejb-jar.xml with two invalid "res-type" values. One "resource-ref" is used for injection, the other just provides an ENC entry. In both cases, no error is raised.

To test it: deploy ear and browse to http://localhost:8080/ResourceRefWeb/ 
Then take a look at the console to see some status output.
The session bean "ResourceRefTestBean" contains a business method which accesses the injected SessionContext and looks up another ENC SessionContext

> res-type in resource-ref is not checked
> ---------------------------------------
>
>                 Key: EJBTHREE-1863
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1863
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.7
>            Reporter: Wolfgang Knauf
>         Attachments: ResourceRef.ear
>
>
> The "res-type" of the "resource-ref" element in ejb-jar.xml is not verified.
> See the attached sample: neither on deploy nor on JNDI lookup, an error is raised for this xml snippet, which contains an invalid res-type:
> 			<resource-ref>
> 				<res-ref-name>EnvNameOfSessionContext1</res-ref-name>
>  				<res-type>whole.lotta.Crap</res-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 				<injection-target>
> 					<injection-target-class>de.knauf.resourceref.ResourceRefTestBean</injection-target-class>
> 					<injection-target-name>sessionContext1</injection-target-name>
> 			  	</injection-target>
> 			</resource-ref>
> 			<resource-ref>
> 				<res-ref-name>EnvNameOfSessionContext2</res-ref-name>
>  				<res-type>whole.lotta.Crap</res-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 			</resource-ref>
> The class org.jboss.injection.ResourceHandler.loadXmlResourceRefs almost completely ignores the "res-type" element ;-).
> For a "resource-env-ref" element, the "resource-env-ref-type" is validated, though maybe this happens by accident ;-):
> Caused by: java.lang.ClassNotFoundException: asdjavax.ejb.SessionContext from BaseClassLoader at 22adfd{...}
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:448)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClassInternal(Unknown Source)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Unknown Source)
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceEnvRefs(ResourceHandler.java:217)
> 	... 73 more
> So, I would like a similar check for the "resource-ref" res-type.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 15:09:52 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 2 Jul 2009 15:09:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2155) Make parsing of
 bendpoints more error-safe
Message-ID: <265628206.1246561792199.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Make parsing of bendpoints more error-safe
------------------------------------------

                 Key: JBRULES-2155
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2155
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler (flow)
            Reporter: Kris Verlaenen
            Assignee: Kris Verlaenen
             Fix For: 5.1.0.M1


In cases where the bendpoints are not specified as expected in the XML, the parser would throw out exceptions that don't contain a lot of information about the cause.
E.g.
java.lang.NumberFormatException: For input string: ""
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:468)
at java.lang.Integer.<init>(Integer.java:620)
at org.drools.eclipse.flow.ruleflow.core.ConnectionWrapper.stringToBendpoints(ConnectionWrapper.java:94)
at org.drools.eclipse.flow.ruleflow.core.ConnectionWrapper.internalGetBendpoints(ConnectionWrapper.java:65)
at org.drools.eclipse.flow.common.editor.core.ElementConnection.getBendpoints(ElementConnection.java:123)
...

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

        


From jira-events at lists.jboss.org  Thu Jul  2 15:17:51 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 2 Jul 2009 15:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2155) Make parsing of
 bendpoints more error-safe
In-Reply-To: <265628206.1246561792199.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1487975114.1246562271893.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen resolved JBRULES-2155.
-------------------------------------

    Resolution: Done


Done

> Make parsing of bendpoints more error-safe
> ------------------------------------------
>
>                 Key: JBRULES-2155
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2155
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (flow)
>            Reporter: Kris Verlaenen
>            Assignee: Kris Verlaenen
>             Fix For: 5.1.0.M1
>
>
> In cases where the bendpoints are not specified as expected in the XML, the parser would throw out exceptions that don't contain a lot of information about the cause.
> E.g.
> java.lang.NumberFormatException: For input string: ""
> at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
> at java.lang.Integer.parseInt(Integer.java:468)
> at java.lang.Integer.<init>(Integer.java:620)
> at org.drools.eclipse.flow.ruleflow.core.ConnectionWrapper.stringToBendpoints(ConnectionWrapper.java:94)
> at org.drools.eclipse.flow.ruleflow.core.ConnectionWrapper.internalGetBendpoints(ConnectionWrapper.java:65)
> at org.drools.eclipse.flow.common.editor.core.ElementConnection.getBendpoints(ElementConnection.java:123)
> ...

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

        


From jira-events at lists.jboss.org  Thu Jul  2 15:20:51 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Thu, 2 Jul 2009 15:20:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7074) some jars required
 by remote Profile Service clients are not included in client/ or
 client/jboss-clientall.jar
Message-ID: <631441563.1246562451433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

some jars required by remote Profile Service clients are not included in client/ or client/jboss-clientall.jar
--------------------------------------------------------------------------------------------------------------

                 Key: JBAS-7074
                 URL: https://jira.jboss.org/jira/browse/JBAS-7074
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Ian Springer
            Assignee: Scott M Stark
             Fix For: JBossAS-5.2.0.Beta1


The classes from the following jar are missing from jboss-clientall.jar and the jar itself is missing from client/:

   common/lib/jboss-security-aspects.jar

Its corresponding Maven artifact is org.jboss.aspects:jboss-security-aspects.

If I find any others, I will update this JIRA.


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

        


From jira-events at lists.jboss.org  Thu Jul  2 15:28:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 2 Jul 2009 15:28:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-100) SJC/RADeployer:
	Classloading
In-Reply-To: <855624937.1246457871714.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <52672742.1246562931405.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-100.
-----------------------------------

    Resolution: Done


> SJC/RADeployer: Classloading
> ----------------------------
>
>                 Key: JBJCA-100
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-100
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Add a classloader to each deployment unit in the SJC resource adapter deployer.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 14:58:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 2 Jul 2009 14:58:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-103) Javassist 3.11 GA
Message-ID: <1839914087.1246561131576.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Javassist 3.11 GA
-----------------

                 Key: JBJCA-103
                 URL: https://jira.jboss.org/jira/browse/JBJCA-103
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2




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

        


From jira-events at lists.jboss.org  Thu Jul  2 15:44:51 2009
From: jira-events at lists.jboss.org (Gurkan Erdogdu (JIRA))
Date: Thu, 2 Jul 2009 15:44:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-104) Developer
 Documentation Patch for Module building.xml
Message-ID: <255543035.1246563891511.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Developer Documentation Patch for Module building.xml
-----------------------------------------------------

                 Key: JBJCA-104
                 URL: https://jira.jboss.org/jira/browse/JBJCA-104
             Project: JBoss JCA
          Issue Type: Patch
          Components: Documentation
            Reporter: Gurkan Erdogdu
            Assignee: Jesper Pedersen


Patch for developer guides building.xml. Adding some documentation about building.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 15:46:51 2009
From: jira-events at lists.jboss.org (Gurkan Erdogdu (JIRA))
Date: Thu, 2 Jul 2009 15:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-104) Developer
 Documentation Patch for Module building.xml
In-Reply-To: <255543035.1246563891511.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1331059353.1246564011784.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gurkan Erdogdu updated JBJCA-104:
---------------------------------

    Attachment: building.patch


> Developer Documentation Patch for Module building.xml
> -----------------------------------------------------
>
>                 Key: JBJCA-104
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-104
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Documentation
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>         Attachments: building.patch
>
>
> Patch for developer guides building.xml. Adding some documentation about building.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 16:12:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 2 Jul 2009 16:12:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-104) Developer
 Documentation Patch for Module building.xml
In-Reply-To: <255543035.1246563891511.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <197274060.1246565571438.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-104.
-----------------------------------

    Resolution: Done


> Developer Documentation Patch for Module building.xml
> -----------------------------------------------------
>
>                 Key: JBJCA-104
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-104
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Documentation
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>         Attachments: building.patch
>
>
> Patch for developer guides building.xml. Adding some documentation about building.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 16:38:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 2 Jul 2009 16:38:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-104) Developer
 Documentation Patch for Module building.xml
In-Reply-To: <255543035.1246563891511.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <526883160.1246567131691.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-104.
-----------------------------------

    Fix Version/s: 1.0.0.Alpha2
       Resolution: Done


> Developer Documentation Patch for Module building.xml
> -----------------------------------------------------
>
>                 Key: JBJCA-104
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-104
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Documentation
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>         Attachments: building.patch
>
>
> Patch for developer guides building.xml. Adding some documentation about building.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 16:38:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 2 Jul 2009 16:38:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBJCA-104) Developer
 Documentation Patch for Module building.xml
In-Reply-To: <255543035.1246563891511.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1552971049.1246567131512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen reopened JBJCA-104:
-----------------------------------



> Developer Documentation Patch for Module building.xml
> -----------------------------------------------------
>
>                 Key: JBJCA-104
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-104
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Documentation
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>         Attachments: building.patch
>
>
> Patch for developer guides building.xml. Adding some documentation about building.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 18:41:51 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 2 Jul 2009 18:41:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1504) Full Journal
	Compactation
In-Reply-To: <33137475.1234453664451.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1338473396.1246574511475.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1504.
----------------------------------------

    Resolution: Done


> Full Journal Compactation
> -------------------------
>
>                 Key: JBMESSAGING-1504
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1504
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> Let me describe how I think the compacting should work.
> Let's say we have a set of files in the journal:
> F0, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10
> min files is set to 10
> The current file is F6 and F7, F8, F9, F10 are unused files waiting to be used
> F0, F1, F2, F3, F4, F5 are files full of data and not open any more, however, data about their contents are stored in memory.
> We need a compacting thread that intermittently (say every 30 seconds) scans the set of journal files in memory.
> It scans F0... F5, and when it has completed that scan, it can decide which records are no longer needed in each file.
> A record is no longer needed in a file if it has already been deleted in any file F0.. F5.
> Once the scanner thread has computed which records are needed and which are not, it can compute a percentage of which records in total are dead space.
> E.g. the scanner might compute that 72% of the data in files F0.. .F5 are dead space.
> We then have a parameter that the user can configure compactorDeadSpaceThresholdPercentage, e.g. this might have a default of 75%.
> If the amount of dead space computed by the scanner >= compactorDeadSpaceThresholdPercentage, then the scanner will compact those files.
> The actual compacting approach goes as follows:
> The scanner knows how many new files it will need for the compacted records, let's say it needs two new files - it can get these from the unused files (e.g. F7, F8, F9 or F10) if they are available.
> It then opens the old files F0..F5 loads the wanted records into memory in blocks and copies them to the new files.
> When this process is finished it will end up with, say, two new files containing the compacted records.
> We can then save a marker file (empty in the journal directory) which says we are starting the rename.
> The old files F0..F5 then need to be renamed so they are no longer used by the journal (but can be recovered in case of a crash).
> Then the two new files need to be renamed so they will be picked up by the journal.
> When that process completes the marker file can be deleted.
> If the server crashes after renaming the old files but before renaming the new files, then the marker file will still exist in the journal. The journal can detect this on startup, and finish the process.
> This ensures the journal will still startup after such a crash.
> Also the JournalFile objects also need to be updated in memory when the compact is complete.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 20:32:51 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 2 Jul 2009 20:32:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2156) Improved BPMN2
	skin
Message-ID: <1369383098.1246581171419.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Improved BPMN2 skin
-------------------

                 Key: JBRULES-2156
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2156
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-eclipse (flow)
            Reporter: Kris Verlaenen
            Assignee: Kris Verlaenen
             Fix For: 5.1.0.M1




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

        


From jira-events at lists.jboss.org  Thu Jul  2 23:25:51 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 2 Jul 2009 23:25:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JASSIST-86) Make concurrent
 calls to getRefClasses() safe.
In-Reply-To: <119743334.1246548771405.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1821628319.1246591551506.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JASSIST-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474773#action_12474773 ] 

Shigeru Chiba commented on JASSIST-86:
--------------------------------------

This patch was provided by Paolo 'Blaisorblade' Giarrusso.

> Make concurrent calls to getRefClasses() safe.
> ----------------------------------------------
>
>                 Key: JASSIST-86
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-86
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>            Reporter: Shigeru Chiba
>            Assignee: Shigeru Chiba
>             Fix For: 3.11.0.GA
>
>         Attachments: fix-javassist-concurrency
>
>
> There is a race condition when getRefClasses is called twice concurrently on
> the same class - one of the chains in HashMap for collision resolution can become
> cyclic, i.e. an infinitely long list, causing iteration on the list to enter an
> infinite loop.
> On a CtClass ct, the call path leading to the problem is:
> ct.getRefClasses() -> ct.renameClass() (it's a fake renameClass(), which does
> not rename anything) -> ct.constPool.renameClass()
> One can thus have concurrent calls to ct.constPool.renameClass(); a constPool
> then recreates the internal HashMap, i.e. reinserts again all elements into
> cp.classes (not a temporary map), so we have concurrent accesses to this map.
> In particular, since there can be a collision (as happened for me), the
> collision chain could become cyclic.
> This was found through remote debugging on a concurrent program using Javassist
> (attaching after a series of run-client invocations ended in a crash). It was a
> real-world program, not a client written on purpose to show this.
> This patch solves the problem well, and was tested in a configuration which caused a
> lot of crashes and stopped causing any.
> Lots of better fixes to this could be thought, but they're more invasive.

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

        


From jira-events at lists.jboss.org  Thu Jul  2 23:27:51 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 2 Jul 2009 23:27:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JASSIST-87) ClassFile.prune()
 makes a constant pool empty.
In-Reply-To: <150232651.1246549431739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <891259711.1246591671777.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JASSIST-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474775#action_12474775 ] 

Shigeru Chiba commented on JASSIST-87:
--------------------------------------

This bug was reported by Paolo 'Blaisorblade' Giarrusso, who also provided the fix.

> ClassFile.prune() makes a constant pool empty.
> ----------------------------------------------
>
>                 Key: JASSIST-87
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-87
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>            Reporter: Shigeru Chiba
>            Assignee: Shigeru Chiba
>             Fix For: 3.11.0.GA
>
>         Attachments: fix-javassist-prune
>
>
> ClassFile.prune calls ConstPool.prune(), which empties the Constant Pool completely.

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

        


From jira-events at lists.jboss.org  Fri Jul  3 00:27:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 3 Jul 2009 00:27:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-94)
 JBossASConfigurationInitializer has wrong default bind address
Message-ID: <477561768.1246595271936.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBossASConfigurationInitializer has wrong default bind address
--------------------------------------------------------------

                 Key: JBBOOT-94
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-94
             Project: JBoss Bootstrap
          Issue Type: Bug
          Components: spi-as
    Affects Versions: 2.0.0-alpha-1
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 2.0.0-beta-1 


String VALUE_BIND_ADDRESS_DEFAULT = "127.0.0.0"; 

...should be "127.0.0.1".

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

        


From jira-events at lists.jboss.org  Fri Jul  3 00:29:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 3 Jul 2009 00:29:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-94)
 JBossASConfigurationInitializer has wrong default bind address
In-Reply-To: <477561768.1246595271936.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1974688679.1246595391880.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated JBBOOT-94:
--------------------------------------

    Fix Version/s: spi-as-2.0.0-alpha-2 
                       (was: 2.0.0-beta-1 )


> JBossASConfigurationInitializer has wrong default bind address
> --------------------------------------------------------------
>
>                 Key: JBBOOT-94
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-94
>             Project: JBoss Bootstrap
>          Issue Type: Bug
>          Components: spi-as
>    Affects Versions: 2.0.0-alpha-1
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: spi-as-2.0.0-alpha-2 
>
>
> String VALUE_BIND_ADDRESS_DEFAULT = "127.0.0.0"; 
> ...should be "127.0.0.1".

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

        


From jira-events at lists.jboss.org  Fri Jul  3 01:42:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 3 Jul 2009 01:42:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-94)
 JBossASConfigurationInitializer has wrong default bind address
In-Reply-To: <477561768.1246595271936.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1090570345.1246599771458.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-94.
---------------------------------------

    Resolution: Done


> JBossASConfigurationInitializer has wrong default bind address
> --------------------------------------------------------------
>
>                 Key: JBBOOT-94
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-94
>             Project: JBoss Bootstrap
>          Issue Type: Bug
>          Components: spi-as
>    Affects Versions: 2.0.0-alpha-1
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: spi-as-2.0.0-alpha-2 
>
>
> String VALUE_BIND_ADDRESS_DEFAULT = "127.0.0.0"; 
> ...should be "127.0.0.1".

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

        


From jira-events at lists.jboss.org  Fri Jul  3 03:12:51 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Fri, 3 Jul 2009 03:12:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1006) Shared transport:
 shunned multiple channels can not reconnect
In-Reply-To: <1360522755.1246439551381.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <503893208.1246605171588.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Blagojevic updated JGRP-1006:
--------------------------------------

    Fix Version/s: 2.8


> Shared transport: shunned multiple channels can not reconnect 
> --------------------------------------------------------------
>
>                 Key: JGRP-1006
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1006
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6
>            Reporter: Vladimir Blagojevic
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>
> Brian Stansberry said:
> One of the EJB3/AS integration testsuite runs hit a JGroups problem last 
> night. *Looks like* some issue between the two AS nodes (127.0.0.1 and 
> 127.0.0.2) in the test caused the channels in one node to be 
> suspected/reconnect. Which didn't go well -- which is the subject of 
> this thread.
> I have the server logs from both, which record at INFO or above; if 
> anyone wants them, ping me. Here are the highlights:
> 1) Both nodes connect 4 channels as part of AS startup: 3 using a shared 
> transport UDP stack (for JBC, HAPartition, JBM) and one TCP one for JBM.
> 2) A bunch of test cases then execute, each deploys an EJB3 jar on each 
> node in turn, which in turn causes another JBC channel to be created and 
> connect at test start and disconnect and close at test end. This channel 
> uses the same shared  transport as the other 3, so now there are four 
> channels using that shared transport.
> 3) This create/close cycle continues a while, until on one node there is 
> some issue that results in one of the 4 UDP channels suspecting its peer 
> and all 4 UDP channels getting a new view:
> 13:23:58,150 INFO  [DefaultPartition] Suspected member: 127.0.0.1:40089
> 13:23:58,257 INFO  [GroupMember] 
> org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 4cfcb4de 
> got new view [127.0.0.2:42088|2] [127.0.0.2:42088], old view is 
> [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088]
> 13:23:58,257 INFO  [GroupMember] I am (127.0.0.2:42088)
> 13:23:58,265 INFO  [DefaultPartition] New cluster view for partition 
> DefaultPartition (id: 2, delta: -1) : [127.0.0.2:1099]
> 13:23:58,275 INFO  [MessagingPostOffice] JBoss Messaging is failing over 
> for failed node 0. If there are many messages to reload this may take 
> some time...
> 13:23:58,442 INFO  [DefaultPartition] I am (127.0.0.2:1099) received 
> membershipChanged event:
> 13:23:58,442 INFO  [DefaultPartition] Dead members: 1 ([127.0.0.1:1099])
> 13:23:58,442 INFO  [DefaultPartition] New Members : 0 ([])
> 13:23:58,442 INFO  [DefaultPartition] All Members : 1 ([127.0.0.2:1099])
> 13:23:58,581 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|2] [127.0.0.2:42088]
> 13:23:58,620 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|2] [127.0.0.2:42088]
> 13:24:00,260 WARN  [GMS] 127.0.0.2:42088 failed to collect all ACKs (1) 
> for mcasted view [127.0.0.2:42088|2] [127.0.0.2:42088] after 2000ms, 
> missing ACKs from [127.0.0.2:42088] (received=[]), 
> local_addr=127.0.0.2:42088
> 13:24:00,661 INFO  [MessagingPostOffice] JBoss Messaging failover completed
> 13:24:00,662 INFO  [GroupMember] Dead members: 1 ([127.0.0.1:40089])
> 13:24:00,662 INFO  [GroupMember] All Members : 1 ([127.0.0.2:42088])
> 4) At some point the suspected node realizes it is suspected and the 4 
> UDP channels decide to reconnect, two at about the same time and the 
> other two w/in 55 ms of the first two:
> 13:24:39,294 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,295 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,315 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,339 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,359 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,360 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,380 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 5) This is where things break down.  It looks like one of the 4 channels 
> is able to get a local_addr, but the others get null. Perhaps a 
> concurrency bug in Configurator.startProtocolStack? (Note the first 2 
> lines below have to do with the independent TCP channel used by JBM; I 
> post them for completeness.)
> 13:24:39,568 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:39,959 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:40,833 WARN  [GMS]
> 13:24:40,834 WARN  [GMS]
> 13:24:41,362 INFO  [STDOUT]
> ---------------------------------------------------------
> GMS: address is 127.0.0.1:56000 (cluster=DefaultPartition-SFSBCache)
> ---------------------------------------------------------
> 13:24:41,362 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,488 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|3] [127.0.0.2:42088, 127.0.0.1:56000]
> 13:24:41,564 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,564 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,927 INFO  [LegacyStateTransferIntegrator] Using version 4096
> 13:24:45,941 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
> 13:24:45,993 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:7900, 127.0.0.1:7900]
> 13:24:45,995 WARN  [GMS] merge was supposed to be cancelled at merge 
> participant 127.0.0.1:7900 (merge_id=[127.0.0.1:7900|1246037080987]), 
> but it is not since merge ids do not match
> 13:24:46,029 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
> 13:24:46,029 WARN  [GMS] resume([127.0.0.1:40089|1246037080833]) does 
> not match null
> 6) Thereafter, there is continual looping of the CloserThread as it 
> tries to connect a channel, fails due to local_addr == null, waits 1 sec 
> and tries again, which goes on for hours:
> 13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> As I said, I suspect a concurrency issue that's resulting in one channel 
> getting a local_addr but thereafter others with the same shared 
> transport get null.
> Hmm, just noticed: the looping in #6 above repeats every 30 secs, not 
> every second. Which is the timeout in JChannel.startStack() :
> /* Wait LOCAL_ADDR_TIMEOUT milliseconds for local_addr to have a 
> non-null value (set by SET_LOCAL_ADDRESS) */
> local_addr=local_addr_promise.getResult(LOCAL_ADDR_TIMEOUT);
> if(local_addr == null) {
>      log.fatal("local_addr is null; cannot connect");
>      throw new ChannelException("local_addr is null");
> }
> So, seems the recurring problem is local_addr_promise isn't getting set, 
> not that it is getting set, but with a null value. *However* the *first* 
> set of FATAL logging occurs just a couple seconds after GMS logs it is 
> going to reconnect. So that first issue where local_addr == null is not 
> due to a timeout.

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

        


From jira-events at lists.jboss.org  Fri Jul  3 03:14:51 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 3 Jul 2009 03:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1863) res-type in
 resource-ref is not checked
In-Reply-To: <2026359205.1246559811397.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <227271483.1246605291420.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned EJBTHREE-1863:
--------------------------------------

    Assignee: jaikiran pai


> res-type in resource-ref is not checked
> ---------------------------------------
>
>                 Key: EJBTHREE-1863
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1863
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.7
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>         Attachments: ResourceRef.ear
>
>
> The "res-type" of the "resource-ref" element in ejb-jar.xml is not verified.
> See the attached sample: neither on deploy nor on JNDI lookup, an error is raised for this xml snippet, which contains an invalid res-type:
> 			<resource-ref>
> 				<res-ref-name>EnvNameOfSessionContext1</res-ref-name>
>  				<res-type>whole.lotta.Crap</res-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 				<injection-target>
> 					<injection-target-class>de.knauf.resourceref.ResourceRefTestBean</injection-target-class>
> 					<injection-target-name>sessionContext1</injection-target-name>
> 			  	</injection-target>
> 			</resource-ref>
> 			<resource-ref>
> 				<res-ref-name>EnvNameOfSessionContext2</res-ref-name>
>  				<res-type>whole.lotta.Crap</res-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 			</resource-ref>
> The class org.jboss.injection.ResourceHandler.loadXmlResourceRefs almost completely ignores the "res-type" element ;-).
> For a "resource-env-ref" element, the "resource-env-ref-type" is validated, though maybe this happens by accident ;-):
> Caused by: java.lang.ClassNotFoundException: asdjavax.ejb.SessionContext from BaseClassLoader at 22adfd{...}
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:448)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClassInternal(Unknown Source)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Unknown Source)
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceEnvRefs(ResourceHandler.java:217)
> 	... 73 more
> So, I would like a similar check for the "resource-ref" res-type.

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

        


From jira-events at lists.jboss.org  Fri Jul  3 03:16:51 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 3 Jul 2009 03:16:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1862) False WARN
 message if res-type is missing in resource-ref
In-Reply-To: <455794687.1246559091538.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <586809558.1246605411471.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned EJBTHREE-1862:
--------------------------------------

    Assignee: jaikiran pai


> False WARN message if res-type is missing in resource-ref
> ---------------------------------------------------------
>
>                 Key: EJBTHREE-1862
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1862
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.7
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>            Priority: Minor
>
> This one was introduced by https://jira.jboss.org/jira/browse/EJBTHREE-1823
> I think this warn message is a slight violation of the spec (chapter 16.7.1.3 of EJB3 spec and 5.6.2 of JavaEE5 spec):
> "The resource-ref element consists of ... the optional res-type .... The res-type element is optional if an injection target is specified for the
> resource; in this case, the res-type defaults to the type of the injection target." 
> So, the warning should only be output if no injection target is specified.

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

        


From jira-events at lists.jboss.org  Fri Jul  3 03:55:51 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 3 Jul 2009 03:55:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBXB-209) Enum parsing
 requires value equal to type name
In-Reply-To: <1699476865.1246607631546.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <922707601.1246607751379.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBXB-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474785#action_12474785 ] 

Thomas Diesler commented on JBXB-209:
-------------------------------------

If I change the type name to 

public enum TAvailability
{
   mandatory("mandatory"), 
   optional("optional");

   ...
}

(which is not a recommended enum type name) - it seems to work

> Enum parsing requires value equal to type name
> ----------------------------------------------
>
>                 Key: JBXB-209
>                 URL: https://jira.jboss.org/jira/browse/JBXB-209
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Thomas Diesler
>
> Caused by: java.lang.RuntimeException: Invalid value mandatory valid are [MANDATORY, OPTIONAL]
> 	at org.jboss.xb.builder.runtime.EnumValueAdapter.cast(EnumValueAdapter.java:136)
> 	at org.jboss.xb.builder.runtime.AbstractPropertyHandler.attribute(AbstractPropertyHandler.java:115)
> 	at org.jboss.xb.binding.sunday.unmarshalling.AttributesHandler.attributes(AttributesHandler.java:51)
> 	at org.jboss.xb.binding.sunday.unmarshalling.DefaultElementHandler.attributes(DefaultElementHandler.java:65)
> 	at org.jboss.xb.builder.runtime.BeanHandler.startParticle(BeanHandler.java:124)
> 	at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:630)
> 	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:401)
> 	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
> public enum TAvailability
> {
>    MANDATORY("mandatory"), 
>    OPTIONAL("optional");
>    private final String value;
>    TAvailability(String v)
>    {
>       value = v;
>    }
>    public String value()
>    {
>       return value;
>    }
>    public static TAvailability fromValue(String v)
>    {
>       for (TAvailability c : TAvailability.values())
>       {
>          if (c.value.equals(v))
>          {
>             return c;
>          }
>       }
>       throw new IllegalArgumentException(v);
>    }
> }

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

        


From jira-events at lists.jboss.org  Fri Jul  3 03:53:51 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 3 Jul 2009 03:53:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-209) Enum parsing requires
 value equal to type name
Message-ID: <1699476865.1246607631546.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Enum parsing requires value equal to type name
----------------------------------------------

                 Key: JBXB-209
                 URL: https://jira.jboss.org/jira/browse/JBXB-209
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.1.GA
            Reporter: Thomas Diesler


Caused by: java.lang.RuntimeException: Invalid value mandatory valid are [MANDATORY, OPTIONAL]
	at org.jboss.xb.builder.runtime.EnumValueAdapter.cast(EnumValueAdapter.java:136)
	at org.jboss.xb.builder.runtime.AbstractPropertyHandler.attribute(AbstractPropertyHandler.java:115)
	at org.jboss.xb.binding.sunday.unmarshalling.AttributesHandler.attributes(AttributesHandler.java:51)
	at org.jboss.xb.binding.sunday.unmarshalling.DefaultElementHandler.attributes(DefaultElementHandler.java:65)
	at org.jboss.xb.builder.runtime.BeanHandler.startParticle(BeanHandler.java:124)
	at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:630)
	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:401)
	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)

public enum TAvailability
{
   MANDATORY("mandatory"), 
   OPTIONAL("optional");

   private final String value;

   TAvailability(String v)
   {
      value = v;
   }

   public String value()
   {
      return value;
   }

   public static TAvailability fromValue(String v)
   {
      for (TAvailability c : TAvailability.values())
      {
         if (c.value.equals(v))
         {
            return c;
         }
      }
      throw new IllegalArgumentException(v);
   }
}

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

        


From jira-events at lists.jboss.org  Fri Jul  3 06:43:52 2009
From: jira-events at lists.jboss.org (Magesh Kumar B (JIRA))
Date: Fri, 3 Jul 2009 06:43:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-2429) Add support for
	Guest role
In-Reply-To: <249552511.1246617831752.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <500852402.1246617832018.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Magesh Kumar B updated JBPORTAL-2429:
-------------------------------------

        Fix Version/s: 2.8 Final
    Affects Version/s: 2.7.1 Final


> Add support for Guest role
> --------------------------
>
>                 Key: JBPORTAL-2429
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2429
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Security
>    Affects Versions: 2.7.1 Final
>            Reporter: Magesh Kumar B
>             Fix For: 2.8 Final
>
>
> Users would like to see a "Welcome" page for unauthenticated users that disappears once the user is logged in. One way of implementing this is to allow a "Guest" role in JBoss Portal security module and the details of which are explained in the forum link.

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

        


From jira-events at lists.jboss.org  Fri Jul  3 06:43:51 2009
From: jira-events at lists.jboss.org (Magesh Kumar B (JIRA))
Date: Fri, 3 Jul 2009 06:43:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2429) Add support for
	Guest role
Message-ID: <249552511.1246617831752.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add support for Guest role
--------------------------

                 Key: JBPORTAL-2429
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2429
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Security
            Reporter: Magesh Kumar B


Users would like to see a "Welcome" page for unauthenticated users that disappears once the user is logged in. One way of implementing this is to allow a "Guest" role in JBoss Portal security module and the details of which are explained in the forum link.

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

        


From jira-events at lists.jboss.org  Fri Jul  3 08:38:51 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 3 Jul 2009 08:38:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-210) Property order cannot
 be defained on super type
Message-ID: <1151868256.1246624731398.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Property order cannot be defained on super type
-----------------------------------------------

                 Key: JBXB-210
                 URL: https://jira.jboss.org/jira/browse/JBXB-210
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.1.GA
            Reporter: Thomas Diesler


Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Property order is not specified for type org.jboss.osgi.blueprint.parser.xb.TReference bound to a sequence. Property order can be specified using @XmlType.propOrder or @XmlAccessorOrder. List of properties: referenceListeners dependsOn initialization componentName description any interfaceNames otherAttributes timeout filter availability
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.assertPropOrderNotRequired(JBossXBNoSchemaBuilder.java:1278)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1071)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:767)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:523)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:482)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1684)

@XmlType(name = "Treference", namespace = BlueprintContext.XMLNS_BLUEPRINT)
public class TReference extends TServiceReference

@XmlType(name = "TserviceReference", namespace = BlueprintContext.XMLNS_BLUEPRINT, propOrder = { "description" })
public class TServiceReference extends TComponent


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

        


From jira-events at lists.jboss.org  Fri Jul  3 09:12:51 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 3 Jul 2009 09:12:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-211) @XmlType.propOrder
 required with no schema sequence
Message-ID: <1202136886.1246626771425.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

@XmlType.propOrder required with no schema sequence
---------------------------------------------------

                 Key: JBXB-211
                 URL: https://jira.jboss.org/jira/browse/JBXB-211
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.1.GA
            Reporter: Thomas Diesler


Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Property order is not specified for type or
g.jboss.osgi.blueprint.parser.xb.TRegistrationListener bound to a sequence. Property order can be sp
ecified using @XmlType.propOrder or @XmlAccessorOrder. List of properties: ref refFIXME bean any unr
egistrationMethod registrationMethod reference
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.assertPropOrderNotRequired(JBossXBNoSchemaBuilder.ja
va:1278)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1071)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:767)
	
Please see forum post

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

        


From jira-events at lists.jboss.org  Fri Jul  3 09:28:03 2009
From: jira-events at lists.jboss.org (Sandeep Vaid (JIRA))
Date: Fri, 3 Jul 2009 09:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-117) Part of
 Composite-Id is foreign Key:How specify in Mapping?
Message-ID: <1444322357.1246627683417.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Part of Composite-Id is foreign Key:How specify in Mapping?
-----------------------------------------------------------

                 Key: HIBERNATE-117
                 URL: https://jira.jboss.org/jira/browse/HIBERNATE-117
             Project: Hibernate
          Issue Type: Feature Request
            Reporter: Sandeep Vaid
            Assignee: Steve Ebersole


 I have 2 classes viz. Product and ProductBasic having one-to-one relationship
  
  class Product{
   String productId;
   ProductBasic productBasic;
   }
   
   class ProductBasic{
    String productId;
    String useCode;
    TimeStamp startTime;
   
    Product product;
   }
   
   Product is mapped to a table PRODUCT which has PRODUCTID as PK.
   ProductBasic is mapped to a table PRODUCTBASIC which has PRODUCTID,USECODE and STARTTTIME as composite key. 
   Also PRODUCTID (of PRODUCTBASIC table) is the foreign key referencing PRODUCT table...
   
  How can i define my one-to-one mapping considering ProductBasic.productId should get its value from Product.productId ?
  
  
  <composite-id>
    <key-property name="productId" column="PRODUCTID" type="string" length="10" />
    <key-property name="useCode" column="USECODE" type="string" length="10" />
    <key-property name="startTime" column="STARTTIME" />
  <composite-id>
  
  In this only productId is the foreign key..
  
  I am aware that i can use a <generator> tag (with class="foreign") inside <composite-id> but i guess it will generate the
  value for entire composite-id and not just a field of it.

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

        


From jira-events at lists.jboss.org  Fri Jul  3 09:33:51 2009
From: jira-events at lists.jboss.org (anil kumar (JIRA))
Date: Fri, 3 Jul 2009 09:33:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7075) Communication from
 JSP (scriptlet) to managed bean is not working
Message-ID: <1063056811.1246628031416.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Communication from JSP (scriptlet) to managed bean is not working
-----------------------------------------------------------------

                 Key: JBAS-7075
                 URL: https://jira.jboss.org/jira/browse/JBAS-7075
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Integration
    Affects Versions: JBossAS-5.1.0.GA
         Environment: windows
            Reporter: anil kumar
            Priority: Critical


I am trying to set few parameters from JSP scriptlet. Here is the snippet.HeaderBean is a managed bean with dispalyTitle as setters and getters.
here its printing auditlog,auditlog,auditlog with command link instead of dashboard,transaction,auditlog command link.

HeaderBean  scope is request.

Please suggest me on this.


 <h:form>        
            <%
            ArrayList<String> names = new ArrayList<String>();
            names.add("dashboard");
            names.add("transaction");
            names.add("auditlog");
          %>
        
        <%
       
        HttpServletRequest facesRequest = (HttpServletRequest)FacesContext.getCurrentInstance().getExternalContext().getRequest();
        for (String name: names){                
             HeaderBean header = new HeaderBean();         
            header.setDispalyTitle(name);
            facesRequest.setAttribute("HeaderBean", header);               
        %>               
                <h:commandLink title="#{HeaderBean.dispalyTitle}" value= "#{HeaderBean.dispalyTitle}"> </h:commandLink> <br> 
        <%}%>

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

        


From jira-events at lists.jboss.org  Fri Jul  3 09:31:51 2009
From: jira-events at lists.jboss.org (Sandeep Vaid (JIRA))
Date: Fri, 3 Jul 2009 09:31:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-118) one-to-one with
 composite-id must have common CompositeId class
Message-ID: <68055049.1246627911640.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

one-to-one with composite-id must have common CompositeId class
---------------------------------------------------------------

                 Key: HIBERNATE-118
                 URL: https://jira.jboss.org/jira/browse/HIBERNATE-118
             Project: Hibernate
          Issue Type: Bug
            Reporter: Sandeep Vaid
            Assignee: Steve Ebersole


One query before asking this question: 
I can see 2 different sites for Hibernate Bug Tracking: 
 1) Hibernate JIRA - http://opensource.atlassian.com/projects/hibernate/secure/Dashboard.jspa
 2) JBOSS JIRA- This site
Which is the official site? Out of these 2 sites on which i should post the bugs etc.. ?

I have one-to-one relationship between Product and ProductBasic..

I have Product (PId, PDesc) as composite-key
I have ProductBasic (ProductId, ProductDesc) as composite-Key

Case 1: I created one Composite class which is common for both Product and ProductBasic..
class CompProductRelated{
 string pid;
 string pdesc;
}
then try to fetch Product.. It worked !!!

Case 2: If i create seperate Composite class for Product & ProductBasic viz. CompProduct and CompProductBasic respectively as :

class CompProduct{
 string productId;
 string productDesc;
}

and not if i define the mapping accordingly as:
In Product.hbm.xml
  <composite-id name="compProduct" class="CompProduct">
       <key-property name="pid" type="string" column="PRODUCTID" length="10"></key-property>
       <key-property name="desc" type="string" column="DESC" length="10"></key-property>
     </composite-id>

In ProductBasic.hbm.xml
   <composite-id name="compProductBasic" class="CompProductBasic"> 
   	     <key-property name="productId" column="PRODUCTID" type="string" length="10"/>
   	     <key-property name="productDesc" column="DESC1" type="string" length="10"/>
   	  </composite-id>
Now while fetching Product (and internally it will fetch ProductBasic), it gives the following exception:
org.hibernate.TypeMismatchException: Provided id of the wrong type. Expected: class model.CompProductBasic, got class model.CompProduct

So the only approach for one-to-one with composite-id is to have a common compositeId class..
The link http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#mapping-declaration-compositeid 

recommends 3 solutions (3rd being to have a common compositeId class) but as per my understanding 1st and 2nd approach will give exception for one-to-one with composite-id ...

I think this hibenate restriction (of having common CompositeId class for one-to-one relationship) is not good as it puts a constraint on how domain model (java) should be which could not be possible everytime in legacy applications..

NOTE: This is the similar exception if i don't use a seperate class for CompositeId..
      Hibernate docs have a statement about this situation as :
       Unfortunately, this approach to composite identifiers means that a persistent object is its own identifier. There is no convenient "handle" other than the object itself. You must instantiate an instance of the persistent class itself and populate its identifier properties before you can load() the persistent state associated with a composite key. We call this approach an embedded  composite identifier, and discourage it for serious applications.
      
      A second approach is what we call a mapped composite identifier, where the identifier properties named inside the <composite-id> element are duplicated on both the persistent class and a separate identifier class.
      
      <composite-id class="MedicareId" mapped="true">
              <key-property name="medicareNumber"/>
              <key-property name="dependent"/>
      </composite-id>
      
      
 Useful Links : https://forum.hibernate.org/viewtopic.php?f=1&t=993886

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

        


From jira-events at lists.jboss.org  Fri Jul  3 09:36:51 2009
From: jira-events at lists.jboss.org (Sandeep Vaid (JIRA))
Date: Fri, 3 Jul 2009 09:36:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-119) one-to-one with
 property-ref always non-lazy
Message-ID: <1718394486.1246628211457.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

one-to-one with property-ref always non-lazy
--------------------------------------------

                 Key: HIBERNATE-119
                 URL: https://jira.jboss.org/jira/browse/HIBERNATE-119
             Project: Hibernate
          Issue Type: Feature Request
            Reporter: Sandeep Vaid
            Assignee: Steve Ebersole


I have one-to-one relationship between Product and ProductBasic.

PRODUCT ------> PRODUCTID(PK)
PRODUCT ------> PID, CODE, STARTTIME (Composite-key) and PID is FK

In product.hbm.xml
 <one-to-one name="productBasic" cascade="save-update" property-ref="activeProduct" constrained="true">
    <formula>PRODUCTID</formula>
 </one-to-one>
 
 
 ProductBasic.hbm.xml as :
 <properties name="activeProduct">
   <many-to-one name="product" class="Product"  insert="false" update="false" lazy="proxy" />
 </properties>
  
  
  When i am using property-ref, and try to load all Products, it fetches ProductBasic also as :
  select * from PRODUCT;   //suppose it return 2 records with productId as 100 and 101 respectively.
  select * from PRODUCTBASIC where productId='100'
  select * from PRODUCTBASIC where productId='101'
 
  How can i fetch ProductBasic in a Non-Lazy manner in this case.


I found few information regarding my problem as :
https://forum.hibernate.org/viewtopic.php?f=25&t=969713

 NOTE: Without property-ref, we can load one-to-one lazily (by sepcifying constrained="true")....... outer-join="true"
  It's shows the message as :
  DEBUG - total objects hydrated: 1
  DEBUG - resolving associations for [model.Product#1]
  DEBUG - loading entity: [model.ProductName#1]
  DEBUG - creating new proxy for entity
  DEBUG - done materializing entity [model.Product#1]
 
  Now the thing now remaining in this is to load one-to-one lazily with property-ref.
  EntityType.resolve() line 382
      if ( isReferenceToPrimaryKey() ) {
 	return resolveIdentifier( (Serializable) value, session );
       }
      else {
        return loadByUniqueKey( getAssociatedEntityName(), uniqueKeyPropertyName, value, session );
       }
     
     and in loadByUniqueKey() method, there is a comment :
     //TODO: implement caching?! proxies?!
     
   I think this is the culprit  

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

        


From jira-events at lists.jboss.org  Fri Jul  3 10:54:51 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 3 Jul 2009 10:54:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-211) @XmlType.propOrder
 required with no schema sequence
In-Reply-To: <1202136886.1246626771425.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1099960275.1246632891454.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBXB-211.
----------------------------------

    Resolution: Rejected
      Assignee: Alexey Loubyansky


The binding is wrong. Sequence is the default model group type.

> @XmlType.propOrder required with no schema sequence
> ---------------------------------------------------
>
>                 Key: JBXB-211
>                 URL: https://jira.jboss.org/jira/browse/JBXB-211
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Thomas Diesler
>            Assignee: Alexey Loubyansky
>
> Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Property order is not specified for type or
> g.jboss.osgi.blueprint.parser.xb.TRegistrationListener bound to a sequence. Property order can be sp
> ecified using @XmlType.propOrder or @XmlAccessorOrder. List of properties: ref refFIXME bean any unr
> egistrationMethod registrationMethod reference
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.assertPropOrderNotRequired(JBossXBNoSchemaBuilder.ja
> va:1278)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1071)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:767)
> 	
> Please see forum post

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

        


From jira-events at lists.jboss.org  Fri Jul  3 10:26:51 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 3 Jul 2009 10:26:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1009) Prevent merging
 during JOIN/LEAVE processing
Message-ID: <1137846767.1246631211429.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Prevent merging during JOIN/LEAVE processing
--------------------------------------------

                 Key: JGRP-1009
                 URL: https://jira.jboss.org/jira/browse/JGRP-1009
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.9


- Say we have V1={A,B,C} and D joins
- A multicasts the new view V2={A,B,C,D} to {A,B,C} and sends a it via unicast to D
- At time T1, A and C have V2, but B might still have V1
- At timeT3 B will also have V2
- HOWEVER, *before* T3 (at T2), A's MERGE functionality gets the current views and discovers the discrepancy
- A will now initiate a merge. This is superfluous because B would have received V2 at T3 (maybe a few ms later) !

This is not incorrect, but we still want to prevent spurious merges.

SOLUTION:
- Turn off merging during view change processing
- This can be done via discarding of MERGE events at GMS during view processing, or by disabling merging directly in MERGE2, MERGE3, MERGEFAST. The first option looks more promising, as it requires only 1 hange in GMS

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

        


From jira-events at lists.jboss.org  Fri Jul  3 10:46:51 2009
From: jira-events at lists.jboss.org (deckrider deckrider (JIRA))
Date: Fri, 3 Jul 2009 10:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-1121) Client
 SocketFactory should be configurable by InvokerLocator
In-Reply-To: <31741702.1239943414266.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1316358662.1246632411548.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBREM-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474838#action_12474838 ] 

deckrider deckrider commented on JBREM-1121:
--------------------------------------------

I see me earlier comment was incomplete.

So I've upgraded to remoting 2.2.3 and added this configuration to jboss-4.2.3.GA/server/default/deploy/ejb3.deployer/META-INF/jboss-service.xml:

   <mbean code="org.jboss.remoting.transport.Connector"
          name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3">
      <depends>jboss.aop:service=AspectDeployer</depends>
      <attribute name="InvokerLocator"><![CDATA[sslsocket://${jboss.bind.address}:3873/?org.jboss.remoting.Remoting.useAllSocketFactoryParams=true&org.jboss.remoting.serverAuthMode=false]]></attribute>
      <attribute name="Configuration">
         <handlers>
            <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>
         </handlers>
      </attribute>
   </mbean>

However, it is not working.  Can anyone help please?

> Client SocketFactory should be configurable by InvokerLocator
> -------------------------------------------------------------
>
>                 Key: JBREM-1121
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1121
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.2.SP11, 2.5.1 (Flounder)
>            Reporter: Ron Sigal
>            Assignee: Ron Sigal
>             Fix For: 2.2.3, 2.5.2 (Flounder)
>
>
> org.jboss.remoting.RemoteClientInvoker, which creates the client invoker's SocketFactory, uses only the parameters passed in the configuration map (except for looking in the InvokerLocator for org.jboss.remoting.SOCKET_FACTORY_CLASS_NAME (actual value "socketFactoryClassName"), which was introduced in JBREM-1014 "Support injection of socket factory class name into AbstractInvoker").  There should be a configurable option to use all parameters from the InvokerLocator.

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

        


From jira-events at lists.jboss.org  Fri Jul  3 11:00:51 2009
From: jira-events at lists.jboss.org (deckrider deckrider (JIRA))
Date: Fri, 3 Jul 2009 11:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-1121) Client
 SocketFactory should be configurable by InvokerLocator
In-Reply-To: <31741702.1239943414266.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2111600095.1246633251710.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBREM-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474840#action_12474840 ] 

deckrider deckrider commented on JBREM-1121:
--------------------------------------------

Never mind, the following works:

<attribute name="InvokerLocator"><![CDATA[sslsocket://${jboss.bind.address}:3873/?useAllSocketFactoryParams=true&org.jboss.remoting.serverAuthMode=false]]></attribute>


> Client SocketFactory should be configurable by InvokerLocator
> -------------------------------------------------------------
>
>                 Key: JBREM-1121
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1121
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.2.SP11, 2.5.1 (Flounder)
>            Reporter: Ron Sigal
>            Assignee: Ron Sigal
>             Fix For: 2.2.3, 2.5.2 (Flounder)
>
>
> org.jboss.remoting.RemoteClientInvoker, which creates the client invoker's SocketFactory, uses only the parameters passed in the configuration map (except for looking in the InvokerLocator for org.jboss.remoting.SOCKET_FACTORY_CLASS_NAME (actual value "socketFactoryClassName"), which was introduced in JBREM-1014 "Support injection of socket factory class name into AbstractInvoker").  There should be a configurable option to use all parameters from the InvokerLocator.

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

        


From jira-events at lists.jboss.org  Fri Jul  3 12:09:51 2009
From: jira-events at lists.jboss.org (Dieter Cailliau (JIRA))
Date: Fri, 3 Jul 2009 12:09:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1068) @Interceptors
 defined on
 @Service EJBs do not have @PostConstruct @PreDestroy interceptor methods
 invoked
In-Reply-To: <18924421.1192225863309.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1121057709.1246637391579.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474850#action_12474850 ] 

Dieter Cailliau commented on EJBTHREE-1068:
-------------------------------------------

I could not get the workaround working for the start() method: the @AroundInvoke never intercepts start(), no matter in which interface it was. This means that i can not use my resources (injected by my interceptor) in the start() implementation of the service, since start() is ran without interception, and always the first call on that service. (jboss 4.2.3) Therefore this workaround isn't of much use to me: i have to call Injector.inject(this) myself in the first line of my start() implementation.


> @Interceptors defined on @Service EJBs do not have @PostConstruct @PreDestroy interceptor methods invoked
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1068
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1068
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>    Affects Versions: AS 4.2.1.GA
>            Reporter: Michael McKibben
>
> I've defined an injection-style interceptor class that needs to be called before a @Service EJBs start() method is invoked on service startup. Using @PostConstruct doesn't not work (the container never calls my @PostConstruct annotated method). @AroundInvoke only works for methods defined on the @Local or @Remote business interface, not the @Management interface.
> Shouldn't @PostConstruct and @PreDestroy be invoked on @Service EJBs? I need my interceptor to behave like the standard injection interceptors do.

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

        


From jira-events at lists.jboss.org  Fri Jul  3 08:38:51 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 3 Jul 2009 08:38:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-210) Property order cannot
 be defined on super type
In-Reply-To: <1151868256.1246624731398.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <698786112.1246624731446.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler updated JBXB-210:
--------------------------------

    Summary: Property order cannot be defined on super type  (was: Property order cannot be defained on super type)


> Property order cannot be defined on super type
> ----------------------------------------------
>
>                 Key: JBXB-210
>                 URL: https://jira.jboss.org/jira/browse/JBXB-210
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Thomas Diesler
>
> Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Property order is not specified for type org.jboss.osgi.blueprint.parser.xb.TReference bound to a sequence. Property order can be specified using @XmlType.propOrder or @XmlAccessorOrder. List of properties: referenceListeners dependsOn initialization componentName description any interfaceNames otherAttributes timeout filter availability
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.assertPropOrderNotRequired(JBossXBNoSchemaBuilder.java:1278)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1071)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:767)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:523)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:482)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1684)
> @XmlType(name = "Treference", namespace = BlueprintContext.XMLNS_BLUEPRINT)
> public class TReference extends TServiceReference
> @XmlType(name = "TserviceReference", namespace = BlueprintContext.XMLNS_BLUEPRINT, propOrder = { "description" })
> public class TServiceReference extends TComponent

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

        


From jira-events at lists.jboss.org  Fri Jul  3 23:00:51 2009
From: jira-events at lists.jboss.org (Ray Ploski (JIRA))
Date: Fri, 3 Jul 2009 23:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-86) Reduce logging noise
 by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1052198926.1246676451461.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ray Ploski updated JBBOOT-86:
-----------------------------

    Attachment: JBBOOT86.patch


Adding the patch this time for real.

> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Andrew Lee Rubinger
>         Attachments: JBBOOT86.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

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

        


From jira-events at lists.jboss.org  Sat Jul  4 02:32:51 2009
From: jira-events at lists.jboss.org (Ray Ploski (JIRA))
Date: Sat, 4 Jul 2009 02:32:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-86) Reduce logging noise
 by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1110014445.1246689171453.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ray Ploski updated JBBOOT-86:
-----------------------------

    Attachment: JBBOOT86-2.patch


JBBOOT86-2.patch uploaded based upon comments.

> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Andrew Lee Rubinger
>         Attachments: JBBOOT86-2.patch, JBBOOT86.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

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

        


From jira-events at lists.jboss.org  Sat Jul  4 12:58:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Sat, 4 Jul 2009 12:58:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-86) Reduce logging
 noise by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <878126092.1246726731699.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-86.
---------------------------------------

    Fix Version/s: 2.0.0-beta-1 
       Resolution: Done


> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-as
>            Reporter: Max Rydahl Andersen
>            Assignee: Ray Ploski
>             Fix For: 2.0.0-beta-1 
>
>         Attachments: JBBOOT86-3.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

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

        


From jira-events at lists.jboss.org  Sat Jul  4 12:09:51 2009
From: jira-events at lists.jboss.org (Ray Ploski (JIRA))
Date: Sat, 4 Jul 2009 12:09:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-86) Reduce logging noise
 by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1985268164.1246723791577.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ray Ploski updated JBBOOT-86:
-----------------------------

    Attachment: JBBOOT86-3.patch


Logging output provides:

	$JBOSS_HOME URL: file:/opt/jems/jbossas/jboss-dev
	Bootstrap: $JBOSS_HOME/server/default/conf/bootstrap.xml
	Common Base: $JBOSS_HOME/common/
	Common Library: $JBOSS_HOME/common/lib/
	Server Name: default
	Server Base: $JBOSS_HOME/server/
	Server Library: $JBOSS_HOME/server/default/lib/
	Server Config: $JBOSS_HOME/server/default/conf/
	Server Home: $JBOSS_HOME/server/default/
	Server Data: $JBOSS_HOME/server/default/data/
	Server Log: $JBOSS_HOME/server/default/log/
	Server Temp: $JBOSS_HOME/server/default/tmp/

Notes:
* the method getPath has been renamed to getRelativePath to better describe function after modifications.
* "$" has been prepended to the relative paths
* File.seperatorChar has been introduced to replace the "/" string in the output.

* StringBuffer has been replaced with StringBuilder in the logServerInfo method

> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Ray Ploski
>         Attachments: JBBOOT86-2.patch, JBBOOT86-3.patch, JBBOOT86.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

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

        


From jira-events at lists.jboss.org  Sat Jul  4 12:11:51 2009
From: jira-events at lists.jboss.org (Ray Ploski (JIRA))
Date: Sat, 4 Jul 2009 12:11:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-86) Reduce logging noise
 by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <426675487.1246723911661.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ray Ploski updated JBBOOT-86:
-----------------------------

    Attachment:     (was: JBBOOT86.patch)


> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Ray Ploski
>         Attachments: JBBOOT86-3.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

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

        


From jira-events at lists.jboss.org  Fri Jul  3 21:49:51 2009
From: jira-events at lists.jboss.org (Ray Ploski (JIRA))
Date: Fri, 3 Jul 2009 21:49:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-86) Reduce logging noise
 by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <327168236.1246672191449.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ray Ploski updated JBBOOT-86:
-----------------------------

    Attachment: JBBOOT86.diff


Hi! I'm uploading a patch that should resolve the issue.  When you are sure the patch will bring no harm to you, execute the following command at the base of your svn project for bootstrap:

patch -p0 -i ~/JBBOOT86.diff

> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Andrew Lee Rubinger
>         Attachments: JBBOOT86.diff
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

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

        


From jira-events at lists.jboss.org  Sat Jul  4 16:11:51 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Sat, 4 Jul 2009 16:11:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7076) DeploymentTemplate
 temp file url is not escaped properly
Message-ID: <1147631592.1246738311392.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

DeploymentTemplate temp file url is not escaped properly
--------------------------------------------------------

                 Key: JBAS-7076
                 URL: https://jira.jboss.org/jira/browse/JBAS-7076
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Scott M Stark
            Assignee: Scott M Stark


The DsDataSourceTemplate applyTemplate method is creating a temp file, but somewhere the file url is not being properly escaped (at least on mac os x), as a temp file name of

/var/folders/jY/jY1BDqLkHKO+a4nm+GooZE+++TI/-Tmp-/DsDataSourceTemplate9162352335796065232-ds.xml

is created, but when the file is accessed by the vfs, it fails with:

java.io.FileNotFoundException: /var/folders/jY/jY1BDqLkHKO a4nm GooZE   TI/-Tmp-/DsDataSourceTemplate9162352335796065232-ds.xml



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

        


From jira-events at lists.jboss.org  Sat Jul  4 12:58:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Sat, 4 Jul 2009 12:58:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-86) Reduce logging noise
 by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <574592917.1246726731845.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated JBBOOT-86:
--------------------------------------

    Component/s: impl-as


> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-as
>            Reporter: Max Rydahl Andersen
>            Assignee: Ray Ploski
>             Fix For: 2.0.0-beta-1 
>
>         Attachments: JBBOOT86-3.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

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

        


From jira-events at lists.jboss.org  Fri Jul  3 22:58:51 2009
From: jira-events at lists.jboss.org (Ray Ploski (JIRA))
Date: Fri, 3 Jul 2009 22:58:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-86) Reduce logging noise
 by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1987347357.1246676331443.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ray Ploski updated JBBOOT-86:
-----------------------------

    Attachment:     (was: JBBOOT86.diff)


> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Andrew Lee Rubinger
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

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

        


From jira-events at lists.jboss.org  Sat Jul  4 16:01:52 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Sat, 4 Jul 2009 16:01:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7050)
 "ClassNotFoundException:
 org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote
 calls to ManagementView.getTemplate()
Message-ID: <1888652206.1246737712000.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-7050.
---------------------------------

    Resolution: Done


The template info server classes are now using writeReplace to only return BasicDeploymentTemplateInfo class.


> "ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote calls to ManagementView.getTemplate()
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7050
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7050
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to create a datasource in AS5 using JON, the following exception occurs:
> java.lang.ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo                                                                                               
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)                                                                                            
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)                                                                                                 
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)                                                                                                                         
>         at java.lang.Class.forName0(Native Method)                                                                                                                                               
>         at java.lang.Class.forName(Class.java:247)                                                                                                                                               
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)                                                                   
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)                                                                                                               
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)                                                                                                                  
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)                                                                                                  
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)                                                                                                               
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)                                                                                                              
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)                                                                                                                 
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)                                                        
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)                                                                  
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)                                                                              
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)                                                                                     
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)                                                                        
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)                                                                             
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)                                                                                                 
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                                    
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                                     
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                            
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                          
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                        
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)                                                                                                                
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)                                                             
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> I was only able to find this class in jboss-embedded-all maven module.

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

        


From jira-events at lists.jboss.org  Sat Jul  4 01:31:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Sat, 4 Jul 2009 01:31:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBOOT-86) Reduce logging
 noise by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1094274044.1246685511447.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474868#action_12474868 ] 

Andrew Lee Rubinger commented on JBBOOT-86:
-------------------------------------------

Forums are down ATM, so I'll do my peer review of the patch discussion here. ;)

1) The patch fails the TestSuite with NPEs.  Check the development instructions: http://www.jboss.org/community/wiki/JBossBootstrapDevelopmentandContribution 

2) This line:

	  // Log full paths when log level Trace is enabled.
      if (log.isTraceEnabled()) 
      {
	    return url.toExternalForm();
      }

...I don't like due to the conditional logic depending upon this log level.  Essentially this creates a case where the test output (with logging set to TRACE) is different than in other environments, and the rest of the method doesn't get tested.  So I'd skip this step.

Let's take another look with those two issues addressed?  Awesome to see your contribution Ray, thanks for getting involved.

> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Andrew Lee Rubinger
>         Attachments: JBBOOT86.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

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

        


From jira-events at lists.jboss.org  Sat Jul  4 11:06:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Sat, 4 Jul 2009 11:06:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBOOT-86) Reduce logging
 noise by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <289412612.1246720011757.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger reassigned JBBOOT-86:
-----------------------------------------

    Assignee: Ray Ploski  (was: Andrew Lee Rubinger)


> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Ray Ploski
>         Attachments: JBBOOT86-2.patch, JBBOOT86.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

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

        


From jira-events at lists.jboss.org  Sat Jul  4 11:20:51 2009
From: jira-events at lists.jboss.org (Luca Stancapiano (JIRA))
Date: Sat, 4 Jul 2009 11:20:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2430) drag and drop
 and partial refresh in a region
Message-ID: <1129829044.1246720851383.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

drag and drop and partial refresh in a region
---------------------------------------------

                 Key: JBPORTAL-2430
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2430
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Core, Portal Theme
    Affects Versions: 2.7.2 Final
         Environment: JBoss Portal 2.7.2 in JBoss 4.2.3 and JBoss 5.1
            Reporter: Luca Stancapiano
             Fix For: 2.8 Final


hi... I added new properties inside the region. With this patch we can decide what region can use partial refresh or drag and drop feature. I've seen that this part is managed in the core but we cannot configure le sngle region for theese properties, so we was forced to use those properties in all the page. I added the two new properties in the org.jboss.portal.theme.tag.RegionTagHandler tag class:


    private String dndEnabled = null;
    private String partialRefreshEnabled = null;

	/**
	 * Attribute handler for the drag and drop of this tag
	 * <p>
	 * This field enables drag and drop on a chosen region
	 * </p>
	 * 
	 * @param dndEnabled
	 *            it can be true or false
	 */
	public void setDndEnabled(String dndEnabled) {
		this.dndEnabled = dndEnabled;
	}

    /**
     * Attribute handler for the partial refresh of this tag
     * <p>
     * This field enables partial refresh on a chosen region
     * </p>
     * 
     * @param partialRefreshEnabled
     *            it can be true or false
     */
    public void setPartialRefreshEnabled(String partialRefreshEnabled) {
        this.partialRefreshEnabled = partialRefreshEnabled;
    }




and this part inside the doTag() method:


			
	    if (dndEnabled != null)
		rrc.getProperties().put(DynaRenderOptions.DND_ENABLED,
		      dndEnabled);
            
            if (partialRefreshEnabled != null)
                rrc.getProperties().put(DynaRenderOptions.PARTIAL_REFRESH_ENABLED,
                      partialRefreshEnabled);



I also updated tag descriptor portal-layout.tld inside core and theme projects adding the new properties:

<taglib
   xmlns="http://java.sun.com/xml/ns/j2ee"
   xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd"
   version="2.0">
   <tlib-version>1.0</tlib-version>
   <jsp-version>2.0</jsp-version>
   <short-name></short-name>
   <uri>http://www.jboss.org/portal</uri>
   <tag>
      <name>region</name>
      <tag-class>org.jboss.portal.theme.tag.RegionTagHandler</tag-class>
      <body-content>empty</body-content>
      <attribute>
         <name>orientation</name>
      </attribute>
      <attribute>
         <name>regionName</name>
      </attribute>
      <attribute>
         <name>regionID</name>
      </attribute>

<---------------------------------------
      <attribute>
         <name>dndEnabled</name>
      </attribute>
      <attribute>
         <name>partialRefreshEnabled</name>
      </attribute>

------------------------------------------
   </tag>





Now, when we want that only some regions uses this properties we can do inside our layout jsp something as:

<p:region regionName='left' regionID='regionA' dndEnabled='true' partialRefreshEnabled='false'/>

If we don't specify that two properties, the region will take the properties of the parent node as well as 

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

        


From jira-events at lists.jboss.org  Sat Jul  4 11:00:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Sat, 4 Jul 2009 11:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBOOT-86) Reduce logging
 noise by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <780247875.1246719651904.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474888#action_12474888 ] 

Andrew Lee Rubinger commented on JBBOOT-86:
-------------------------------------------

This "JBBOOT86-2.patch" is good. :)

Leaves form:

        JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/projects/bootstrap/trunk/impl-as/target/tests-classes/jbossas/
	Bootstrap: JBOSS_HOME/server/default/conf/bootstrap.xml
	Common Base: JBOSS_HOME/common/
	Common Library: JBOSS_HOME/common/lib/
	Server Name: default
	Server Base: JBOSS_HOME/server/
	Server Library: JBOSS_HOME/server/default/lib/
	Server Config: JBOSS_HOME/server/default/conf/
	Server Home: JBOSS_HOME/server/default/
	Server Data: JBOSS_HOME/server/default/data
	Server Log: JBOSS_HOME/server/default/log
	Server Temp: JBOSS_HOME/server/default/tmp

Some minor notes:

1) Let's prepend a "$" to the cut path, make into "$JBOSS_HOME"
2) Can "getPath" be something a bit more descriptive?  "getRelativePath(String base,URL actual )" perhaps?
3) The "/" in "getPath" should be File.separatorChar so we're not OS-specific

...then we'll have Ray do the honors of a commit.  Just put "JBBOOT-86" somewhere in the commit message.

> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Andrew Lee Rubinger
>         Attachments: JBBOOT86-2.patch, JBBOOT86.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

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

        


From jira-events at lists.jboss.org  Sat Jul  4 12:11:51 2009
From: jira-events at lists.jboss.org (Ray Ploski (JIRA))
Date: Sat, 4 Jul 2009 12:11:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-86) Reduce logging noise
 by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1890814077.1246723911551.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ray Ploski updated JBBOOT-86:
-----------------------------

    Attachment:     (was: JBBOOT86-2.patch)


> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Ray Ploski
>         Attachments: JBBOOT86-3.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

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

        


From jira-events at lists.jboss.org  Sun Jul  5 12:39:51 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Sun, 5 Jul 2009 12:39:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-288) Errors show up in
	problems view
In-Reply-To: <13325945.1231384923985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <713252756.1246811991401.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-288.
---------------------------

    Resolution: Done


> Errors show up in problems view
> -------------------------------
>
>                 Key: GPD-288
>                 URL: https://jira.jboss.org/jira/browse/GPD-288
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>            Priority: Critical
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Process errors (e.g. duplicate node names) should show up in the problems view and should have the 'problem' annotation.

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

        


From jira-events at lists.jboss.org  Sun Jul  5 15:15:51 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Sun, 5 Jul 2009 15:15:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1863) res-type in
 resource-ref is not checked
In-Reply-To: <2026359205.1246559811397.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <993243095.1246821351652.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolfgang Knauf updated EJBTHREE-1863:
-------------------------------------

    Attachment: ResourceRef.ear


Version 2 of the sample, with two more "java:/comp/EJBContext" bindings through "<resource-env-ref>", one with injection, the other with a lookup.

It shows that for a "<resource-env-ref>", the "<resource-env-ref-type>" is not validated against the type of the JNDI lookup result, it is just checked that the class can be found in the current classloader.

So, the final goal should probably be to make "resource-env-ref" and "resource-ref" use the same validation code.

A side effect of my sample is that it works around https://jira.jboss.org/jira/browse/EJBTHREE-1858 , because 1858 first checks the type, then performs some specific actions according to the type, and the type does not match in my sample.

> res-type in resource-ref is not checked
> ---------------------------------------
>
>                 Key: EJBTHREE-1863
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1863
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.7
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>         Attachments: ResourceRef.ear, ResourceRef.ear
>
>
> The "res-type" of the "resource-ref" element in ejb-jar.xml is not verified.
> See the attached sample: neither on deploy nor on JNDI lookup, an error is raised for this xml snippet, which contains an invalid res-type:
> 			<resource-ref>
> 				<res-ref-name>EnvNameOfSessionContext1</res-ref-name>
>  				<res-type>whole.lotta.Crap</res-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 				<injection-target>
> 					<injection-target-class>de.knauf.resourceref.ResourceRefTestBean</injection-target-class>
> 					<injection-target-name>sessionContext1</injection-target-name>
> 			  	</injection-target>
> 			</resource-ref>
> 			<resource-ref>
> 				<res-ref-name>EnvNameOfSessionContext2</res-ref-name>
>  				<res-type>whole.lotta.Crap</res-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 			</resource-ref>
> The class org.jboss.injection.ResourceHandler.loadXmlResourceRefs almost completely ignores the "res-type" element ;-).
> For a "resource-env-ref" element, the "resource-env-ref-type" is validated, though maybe this happens by accident ;-):
> Caused by: java.lang.ClassNotFoundException: asdjavax.ejb.SessionContext from BaseClassLoader at 22adfd{...}
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:448)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClassInternal(Unknown Source)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Unknown Source)
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceEnvRefs(ResourceHandler.java:217)
> 	... 73 more
> So, I would like a similar check for the "resource-ref" res-type.

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

        


From jira-events at lists.jboss.org  Sun Jul  5 17:52:51 2009
From: jira-events at lists.jboss.org (Vasile Alaiba (JIRA))
Date: Sun, 5 Jul 2009 17:52:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-741) Issues with
	aophelper.bat
Message-ID: <1981652518.1246830771395.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Issues with aophelper.bat 
--------------------------

                 Key: JBAOP-741
                 URL: https://jira.jboss.org/jira/browse/JBAOP-741
             Project: JBoss AOP
          Issue Type: Patch
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.3.GA
            Reporter: Vasile Alaiba
            Priority: Trivial


aophelper.bat does not work if spaces are part of the path. It also has some issues setting up the CLASSPATH.

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

        


From jira-events at lists.jboss.org  Sun Jul  5 17:54:51 2009
From: jira-events at lists.jboss.org (Vasile Alaiba (JIRA))
Date: Sun, 5 Jul 2009 17:54:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-741) Issues with
	aophelper.bat
In-Reply-To: <1981652518.1246830771395.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <213282560.1246830891402.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAOP-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vasile Alaiba updated JBAOP-741:
--------------------------------

    Attachment: aophelper.bat


> Issues with aophelper.bat 
> --------------------------
>
>                 Key: JBAOP-741
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-741
>             Project: JBoss AOP
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.3.GA
>            Reporter: Vasile Alaiba
>            Priority: Trivial
>         Attachments: aophelper.bat
>
>
> aophelper.bat does not work if spaces are part of the path. It also has some issues setting up the CLASSPATH.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 02:59:51 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 6 Jul 2009 02:59:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMETA-213) add JCA DTD files
In-Reply-To: <2485970.1245738836463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <307840146.1246863591485.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang reopened JBMETA-213:
-------------------------------



update dtd files and add testcase

> add JCA DTD files
> -----------------
>
>                 Key: JBMETA-213
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-213
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.2.Beta2, 2.0.0.CR1
>
>
> add connector_1_5.dtd and connector_1_6.dtd into metadata/trunk and metadata/rar

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

        


From jira-events at lists.jboss.org  Mon Jul  6 03:50:03 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 6 Jul 2009 03:50:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMETA-213) add JCA DTD files
In-Reply-To: <2485970.1245738836463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1818254747.1246866603910.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved JBMETA-213.
-------------------------------

    Fix Version/s:     (was: 1.0.2.Beta2)
       Resolution: Done


> add JCA DTD files
> -----------------
>
>                 Key: JBMETA-213
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-213
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 2.0.0.CR1
>
>
> add connector_1_5.dtd and connector_1_6.dtd into metadata/trunk and metadata/rar

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

        


From jira-events at lists.jboss.org  Mon Jul  6 05:16:52 2009
From: jira-events at lists.jboss.org (Nicolas Karageuzian (JIRA))
Date: Mon, 6 Jul 2009 05:16:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7077) ant <jmx> raise
 BuildException for attribute reading error
Message-ID: <2019489997.1246871812125.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

ant <jmx> raise BuildException for attribute reading error
----------------------------------------------------------

                 Key: JBAS-7077
                 URL: https://jira.jboss.org/jira/browse/JBAS-7077
             Project: JBoss Application Server
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-4.0.4.GA
         Environment: All
            Reporter: Nicolas Karageuzian
            Priority: Trivial


add failonerror on <jmx> ant task to perform monitoring without stopping whole ant script while MBean doesn't exists.


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

        


From jira-events at lists.jboss.org  Mon Jul  6 05:21:51 2009
From: jira-events at lists.jboss.org (Nicolas Karageuzian (JIRA))
Date: Mon, 6 Jul 2009 05:21:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7077) ant <jmx> raise
 BuildException for attribute reading error
In-Reply-To: <2019489997.1246871812125.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <911935227.1246872111896.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nicolas Karageuzian updated JBAS-7077:
--------------------------------------

    Attachment: JMXTask.diff


Here is my diff for an optional boolean failonerror attribute, and modifications within execute for error handling.

It affects org.jboss.ant.JMX and helps for monitoring many attributes on many MBeans on many instances with an ant script in a single JVM (versus twiddle which instanciate 1 JVM per instance per MBean).

> ant <jmx> raise BuildException for attribute reading error
> ----------------------------------------------------------
>
>                 Key: JBAS-7077
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7077
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: All
>            Reporter: Nicolas Karageuzian
>            Priority: Trivial
>         Attachments: JMXTask.diff
>
>
> add failonerror on <jmx> ant task to perform monitoring without stopping whole ant script while MBean doesn't exists.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 07:39:51 2009
From: jira-events at lists.jboss.org (Aleksander Adamowski (JIRA))
Date: Mon, 6 Jul 2009 07:39:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1864) Release source
 and javadoc artifacts to Maven repositories
Message-ID: <1250424755.1246880391385.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Release source and javadoc artifacts to Maven repositories
----------------------------------------------------------

                 Key: EJBTHREE-1864
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1864
             Project: EJB 3.0
          Issue Type: Release
          Components: build
    Affects Versions: trunk
            Reporter: Aleksander Adamowski


Currently, most Maven 2 artifacts are released without accompanying source and javadoc artifacts, e.g.:

http://repository.jboss.com/maven2/jboss/jboss-annotations-ejb3/4.2.3.GA/

It would make development work much simpler if the release deployment procedure included source and javadoc.

With Maven 2, this is trivial:

http://maven.apache.org/plugin-developers/cookbook/attach-source-javadoc-artifacts.html

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

        


From jira-events at lists.jboss.org  Mon Jul  6 09:15:59 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 6 Jul 2009 09:15:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1864) Release source
 and javadoc artifacts to Maven repositories
In-Reply-To: <1250424755.1246880391385.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1734047099.1246886159948.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved EJBTHREE-1864.
-------------------------------------------

    Resolution: Rejected
      Assignee: Andrew Lee Rubinger


We've got JavaDoc and Source attachments for the EJB3 releases; everything is under the org.jboss.ejb3 groupId namespace.  For example:


> Release source and javadoc artifacts to Maven repositories
> ----------------------------------------------------------
>
>                 Key: EJBTHREE-1864
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1864
>             Project: EJB 3.0
>          Issue Type: Release
>          Components: build
>    Affects Versions: trunk
>            Reporter: Aleksander Adamowski
>            Assignee: Andrew Lee Rubinger
>
> Currently, most Maven 2 artifacts are released without accompanying source and javadoc artifacts, e.g.:
> http://repository.jboss.com/maven2/jboss/jboss-annotations-ejb3/4.2.3.GA/
> It would make development work much simpler if the release deployment procedure included source and javadoc.
> With Maven 2, this is trivial:
> http://maven.apache.org/plugin-developers/cookbook/attach-source-javadoc-artifacts.html

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

        


From jira-events at lists.jboss.org  Mon Jul  6 09:16:00 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 6 Jul 2009 09:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1864) Release source
 and javadoc artifacts to Maven repositories
In-Reply-To: <1250424755.1246880391385.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <721829908.1246886160062.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated EJBTHREE-1864:
------------------------------------------

    Comment: was deleted


> Release source and javadoc artifacts to Maven repositories
> ----------------------------------------------------------
>
>                 Key: EJBTHREE-1864
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1864
>             Project: EJB 3.0
>          Issue Type: Release
>          Components: build
>    Affects Versions: trunk
>            Reporter: Aleksander Adamowski
>            Assignee: Andrew Lee Rubinger
>
> Currently, most Maven 2 artifacts are released without accompanying source and javadoc artifacts, e.g.:
> http://repository.jboss.com/maven2/jboss/jboss-annotations-ejb3/4.2.3.GA/
> It would make development work much simpler if the release deployment procedure included source and javadoc.
> With Maven 2, this is trivial:
> http://maven.apache.org/plugin-developers/cookbook/attach-source-javadoc-artifacts.html

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

        


From jira-events at lists.jboss.org  Mon Jul  6 09:16:00 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 6 Jul 2009 09:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1864) Release source
 and javadoc artifacts to Maven repositories
In-Reply-To: <1250424755.1246880391385.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <835857373.1246886160187.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475008#action_12475008 ] 

Andrew Lee Rubinger commented on EJBTHREE-1864:
-----------------------------------------------

We've got JavaDoc and Source attachments for the EJB3 releases; everything is under the org.jboss.ejb3 groupId namespace. For example: 

http://repository.jboss.org/maven2/org/jboss/ejb3/jboss-ejb3-ext-api/1.0.0/

> Release source and javadoc artifacts to Maven repositories
> ----------------------------------------------------------
>
>                 Key: EJBTHREE-1864
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1864
>             Project: EJB 3.0
>          Issue Type: Release
>          Components: build
>    Affects Versions: trunk
>            Reporter: Aleksander Adamowski
>            Assignee: Andrew Lee Rubinger
>
> Currently, most Maven 2 artifacts are released without accompanying source and javadoc artifacts, e.g.:
> http://repository.jboss.com/maven2/jboss/jboss-annotations-ejb3/4.2.3.GA/
> It would make development work much simpler if the release deployment procedure included source and javadoc.
> With Maven 2, this is trivial:
> http://maven.apache.org/plugin-developers/cookbook/attach-source-javadoc-artifacts.html

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

        


From jira-events at lists.jboss.org  Mon Jul  6 09:40:52 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 6 Jul 2009 09:40:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-105) SJC/RAdeployer: Add
 support for DTDs
Message-ID: <1880250736.1246887652072.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC/RAdeployer: Add support for DTDs
------------------------------------

                 Key: JBJCA-105
                 URL: https://jira.jboss.org/jira/browse/JBJCA-105
             Project: JBoss JCA
          Issue Type: Task
          Components: Deployer
    Affects Versions: 1.0.0.Alpha1
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha2


Add dtd deployment into sjc deployer

create this task for tacking this function. code commit r90827 should belong this task

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

        


From jira-events at lists.jboss.org  Mon Jul  6 09:56:51 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 6 Jul 2009 09:56:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-105) SJC/RAdeployer: Add
 support for DTDs
In-Reply-To: <1880250736.1246887652072.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1054605650.1246888611414.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang updated JBJCA-105:
-----------------------------

    Affects Version/s:     (was: 1.0.0.Alpha1)


> SJC/RAdeployer: Add support for DTDs
> ------------------------------------
>
>                 Key: JBJCA-105
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-105
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> Add dtd deployment into sjc deployer
> create this task for tacking this function. code commit r90827 should belong this task

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

        


From jira-events at lists.jboss.org  Mon Jul  6 10:17:51 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 6 Jul 2009 10:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1954502403.1246889871735.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky reassigned JBXB-206:
--------------------------------------

    Assignee: Alexey Loubyansky


What I meant is that the issue is probably the resolver is not configured properly. It's not enough to just instantiate it. What namespace is resolved with XsdBinder?

> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>            Assignee: Alexey Loubyansky
>         Attachments: jboss-profiler.properties, jbossxb.zip, server.log.gz
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 10:45:51 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Mon, 6 Jul 2009 10:45:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7078) Create
 SSLSocketFactory that uses a JaasSecurityDomain
Message-ID: <565179297.1246891551731.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Create SSLSocketFactory that uses a JaasSecurityDomain
------------------------------------------------------

                 Key: JBAS-7078
                 URL: https://jira.jboss.org/jira/browse/JBAS-7078
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Marcus Moyses
            Assignee: Marcus Moyses
             Fix For: JBossAS-5.2.0.Beta1


We need a SSLSocketFactory with a default constructor and a static getDefault method that sets up SSL using a JaasSecurityDomain mbean so it can be used for LDAPS, Remoting, etc.
The name of the security domain must be set as a system property.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 11:07:51 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:07:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-355) offer conversion
 support for files from jBPM 3 to jBPM 4
Message-ID: <1159827641.1246892871401.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

offer conversion support for files from jBPM 3 to jBPM 4
--------------------------------------------------------

                 Key: GPD-355
                 URL: https://jira.jboss.org/jira/browse/GPD-355
             Project: JBoss jBPM GPD
          Issue Type: Task
          Components: jpdl
            Reporter: Koen Aers
            Assignee: Koen Aers
            Priority: Minor
             Fix For: jBPM jPDL Designer 4.0.0.GA




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

        


From jira-events at lists.jboss.org  Mon Jul  6 11:10:05 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:10:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-355) offer conversion
 support for files from jBPM 3 to jBPM 4
In-Reply-To: <1159827641.1246892871401.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1220191639.1246893005688.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-355:
--------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)


> offer conversion support for files from jBPM 3 to jBPM 4
> --------------------------------------------------------
>
>                 Key: GPD-355
>                 URL: https://jira.jboss.org/jira/browse/GPD-355
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.0.x
>
>


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

        


From jira-events at lists.jboss.org  Mon Jul  6 11:10:05 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:10:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-301) migration support
In-Reply-To: <17851186.1235491064707.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <216104807.1246893005573.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-301.
---------------------------

    Resolution: Done


The optional part is now issue GPD-355

> migration support
> -----------------
>
>                 Key: GPD-301
>                 URL: https://jira.jboss.org/jira/browse/GPD-301
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>
> things like:
> * make sure that we can work with jBPM 3 and jBPM 4 process files in a single eclipse installation
> * make sure that the files are associated to the correct version of the editor
> * optional: offer conversion support for files

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

        


From jira-events at lists.jboss.org  Mon Jul  6 11:17:51 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-336) image generation
	fails
In-Reply-To: <18908917.1242894356480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1697491408.1246893471964.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/GPD-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475051#action_12475051 ] 

Koen Aers commented on GPD-336:
-------------------------------

Will be fixed later: the workaround is to switch to the graphical tab before saving to have the proper image generation

> image generation fails
> ----------------------
>
>                 Key: GPD-336
>                 URL: https://jira.jboss.org/jira/browse/GPD-336
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> image generation seems to work for org.jbpm.examples.async.activity
> but it seems to fail for org.jbpm.examples.async.fork.  in that case I get an image with only a diagonal line.
> koen, do you get the same with that example ?

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

        


From jira-events at lists.jboss.org  Mon Jul  6 11:17:52 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:17:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-229) Write up the initial
 test scenario's to test the GPD (automated or manual)
In-Reply-To: <9329862.1216376692216.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1903604632.1246893472923.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-229.
---------------------------

    Resolution: Done


> Write up the initial test scenario's to test the GPD (automated or manual)
> --------------------------------------------------------------------------
>
>                 Key: GPD-229
>                 URL: https://jira.jboss.org/jira/browse/GPD-229
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>


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

        


From jira-events at lists.jboss.org  Mon Jul  6 11:17:52 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:17:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-336) image generation fails
In-Reply-To: <18908917.1242894356480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1861503600.1246893472244.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-336:
--------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)
         Priority: Minor  (was: Major)


> image generation fails
> ----------------------
>
>                 Key: GPD-336
>                 URL: https://jira.jboss.org/jira/browse/GPD-336
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> image generation seems to work for org.jbpm.examples.async.activity
> but it seems to fail for org.jbpm.examples.async.fork.  in that case I get an image with only a diagonal line.
> koen, do you get the same with that example ?

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

        


From jira-events at lists.jboss.org  Mon Jul  6 11:21:03 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-334) update jbpm roadmap
 with gpd features
In-Reply-To: <10900511.1242229666628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1964583391.1246893663836.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-334.
---------------------------

    Resolution: Out of Date


> update jbpm roadmap with gpd features
> -------------------------------------
>
>                 Key: GPD-334
>                 URL: https://jira.jboss.org/jira/browse/GPD-334
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>
> http://www.jboss.org/community/docs/DOC-13217

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

        


From jira-events at lists.jboss.org  Mon Jul  6 11:27:52 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 6 Jul 2009 11:27:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1295017179.1246894072528.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475055#action_12475055 ] 

jaikiran pai commented on JBMETA-208:
-------------------------------------

>> 4. If it contains neither a DTD nor a namespace, display a warning that you are entering 'compatibility mode' where you both process the ejb-jar.xml and scan for annotations (at the expense of reduced startup time). The warning should advise the developer 'either add a DTD or a namespace to avoid this warning' 

IMO, it should print out a WARN that will inform the user/dev that the deployment will *not* be scanned for annotations. The developer can then fix it appropriately. This nicely fits in with the requirement that 

1) EJB3 deployment require a namespace 
2) User being notified of an incorrect ejb-jar.xml
3) No additional performance cost.


> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <ejb-jar version="3.0"
>     xmlns="http://java.sun.com/xml/ns/javaee"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 11:32:08 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 6 Jul 2009 11:32:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-531) Build testsuite
 classpaths directly against jars in local maven repository
In-Reply-To: <6026725.1243637396349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <536901684.1246894328153.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBBUILD-531:
-----------------------------------


The JBoss-AS-6.0.x-testSuite-sun16 job,
http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-testSuite-sun16/

is failing with:
BUILD FAILED
/qa/hudson_ws/workspace/JBoss-AS-6.0.x-testSuite-sun16/JBossAS/testsuite/build.xml:1029: The following error occurred while executing this line:
/qa/hudson_ws/workspace/JBoss-AS-6.0.x-testSuite-sun16/JBossAS/testsuite/imports/config/tests-clustering.xml:105: The following error occurred while executing this line:
/qa/hudson_ws/workspace/JBoss-AS-6.0.x-testSuite-sun16/JBossAS/testsuite/imports/config/tests-clustering.xml:240: The following error occurred while executing this line:
/qa/hudson_ws/workspace/JBoss-AS-6.0.x-testSuite-sun16/JBossAS/testsuite/build.xml:395: java.lang.OutOfMemoryError: PermGen space

This appears to be a OOM with maven.  The build is run with:
MAVEN_OPTS="-Xmx1024m -Xms512m -XX:PermSize=256m -XX:MaxPermSize=768m"

I recently made a change to testsuite/imports/config/tests-clustering.xml to add init to the tests-clustering-unit target 
http://fisheye.jboss.org/changelog/JBossAS/?cs=90757
to resolve this:
/qa/hudson_ws/workspace/JBoss-AS-6.0.x-testSuite-sun16/JBossAS/testsuite/imports/config/tests-clustering.xml:392: Reference apache-httpclient:commons-httpclient:jar not found.



> Build testsuite classpaths directly against jars in local maven repository
> --------------------------------------------------------------------------
>
>                 Key: JBBUILD-531
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-531
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the testsuite uses the jars in thirdparty.  Instead the paths in the testsuite should directly reference jars in the local maven repository directory.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 11:32:08 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:32:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-331) Support HQL
 attributes and elements
In-Reply-To: <143992.1241701546509.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1275789815.1246894328417.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-331.
---------------------------

    Resolution: Done


> Support HQL attributes and elements
> -----------------------------------
>
>                 Key: GPD-331
>                 URL: https://jira.jboss.org/jira/browse/GPD-331
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> attributes: var, unique
> elements: query, parameter

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

        


From jira-events at lists.jboss.org  Mon Jul  6 11:32:08 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 6 Jul 2009 11:32:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1761761605.1246894328279.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475058#action_12475058 ] 

Alexey Loubyansky commented on JBMETA-208:
------------------------------------------

You'd have to do it for every EJB2 deployment. In that case it's better just to log the EJB version of the deployment.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <ejb-jar version="3.0"
>     xmlns="http://java.sun.com/xml/ns/javaee"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 11:33:51 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:33:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-341) renaming swimlane
 should make editor dirty
In-Reply-To: <31349923.1243352997231.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1706931486.1246894431910.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-341.
---------------------------

    Resolution: Done


> renaming swimlane should make editor dirty
> ------------------------------------------
>
>                 Key: GPD-341
>                 URL: https://jira.jboss.org/jira/browse/GPD-341
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>


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

        


From jira-events at lists.jboss.org  Mon Jul  6 11:39:53 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:39:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-306) Self Referencing
	Connections
In-Reply-To: <6129383.1237558244506.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <643097081.1246894793293.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-306:
--------------------------

      Component/s: jpdl
    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)
         Priority: Minor  (was: Major)


> Self Referencing Connections
> ----------------------------
>
>                 Key: GPD-306
>                 URL: https://jira.jboss.org/jira/browse/GPD-306
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> There should be a convenient way to create connections that reference the same node as source and target

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

        


From jira-events at lists.jboss.org  Mon Jul  6 11:39:53 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:39:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-306) Self Referencing
	Connections
In-Reply-To: <6129383.1237558244506.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <190140969.1246894793236.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/GPD-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475063#action_12475063 ] 

Koen Aers commented on GPD-306:
-------------------------------

 Postponed until a later version: workaround is to add the transition manually in the xml view

> Self Referencing Connections
> ----------------------------
>
>                 Key: GPD-306
>                 URL: https://jira.jboss.org/jira/browse/GPD-306
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> There should be a convenient way to create connections that reference the same node as source and target

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

        


From jira-events at lists.jboss.org  Mon Jul  6 12:10:51 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Mon, 6 Jul 2009 12:10:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7078) Create
 SSLSocketFactory that uses a JaasSecurityDomain
In-Reply-To: <565179297.1246891551731.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1687217202.1246896651420.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcus Moyses resolved JBAS-7078.
---------------------------------

    Resolution: Done


org.jboss.security.ssl.JaasSecurityDomainSocketFactory was created for this purpose.
By default it expects the security domain name in the org.jboss.security.ssl.domain.name system property. 

> Create SSLSocketFactory that uses a JaasSecurityDomain
> ------------------------------------------------------
>
>                 Key: JBAS-7078
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7078
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Marcus Moyses
>            Assignee: Marcus Moyses
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> We need a SSLSocketFactory with a default constructor and a static getDefault method that sets up SSL using a JaasSecurityDomain mbean so it can be used for LDAPS, Remoting, etc.
> The name of the security domain must be set as a system property.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 12:22:51 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Mon, 6 Jul 2009 12:22:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-533) Update jboss
 parent pom and
 wiki to use webdav for deploying to releases repository
Message-ID: <614718933.1246897371972.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Update jboss parent pom and wiki to use webdav for deploying to releases repository
-----------------------------------------------------------------------------------

                 Key: JBBUILD-533
                 URL: https://jira.jboss.org/jira/browse/JBBUILD-533
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven Builds
            Reporter: Paul Gier
             Fix For: Maven Build - Maint 2009


The webdav URL (dav:https://svn.jboss.org/repos/repository.jboss.org/maven2) should be used when deploying to the jboss maven repository instead of the current method of checkout out the repository first.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 13:40:51 2009
From: jira-events at lists.jboss.org (Naresh Bhatia (JIRA))
Date: Mon, 6 Jul 2009 13:40:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1677) "Connection
 failure has been detected" message
Message-ID: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

"Connection failure has been detected" message
----------------------------------------------

                 Key: JBMESSAGING-1677
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0.beta3
         Environment: Windows XP SP2
            Reporter: Naresh Bhatia
            Assignee: Tim Fox


I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.

Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 

22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
om server:3
...
23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
ient. It is likely a client has exited or crashed without closing its connection, or the network bet
ween the server and client has failed. The connection will now be closed.:3
23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
8-11de-9025-0016d433fcb5
23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5



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

        


From jira-events at lists.jboss.org  Mon Jul  6 13:42:51 2009
From: jira-events at lists.jboss.org (Naresh Bhatia (JIRA))
Date: Mon, 6 Jul 2009 13:42:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1933608586.1246902171467.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Naresh Bhatia updated JBMESSAGING-1677:
---------------------------------------

    Attachment: JmsTest.zip


Attaching file.

> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Tim Fox
>         Attachments: JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

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

        


From jira-events at lists.jboss.org  Mon Jul  6 14:00:51 2009
From: jira-events at lists.jboss.org (Bob Shanahan (JIRA))
Date: Mon, 6 Jul 2009 14:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-5922) Allow shutdown.sh
 to still work if it passed a http(s) jndi url
In-Reply-To: <11373674.1220431139264.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <202009484.1246903251829.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475085#action_12475085 ] 

Bob Shanahan commented on JBAS-5922:
------------------------------------

The JNDI url ends with JNDIFactory, not JNDIProxy, hence the shutdown command is

shutdown.sh -s http://localhost:8080/invoker/JNDIFactory -S

If using the 'nix service script, change the stop command to the following:

JBOSS_CMD_STOP=${JBOSS_CMD_STOP:-"java -classpath $JBOSSCP org.jboss.Shutdown -s http://localhost:8080/invoker/JNDIFactory



> Allow shutdown.sh to still work if it passed a http(s) jndi url
> ---------------------------------------------------------------
>
>                 Key: JBAS-5922
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5922
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>            Reporter: Adrian Brock
>            Assignee: Adrian Brock
>             Fix For: JBossAS-5.0.0.CR2
>
>
> If shutdown.sh|.bat is passed a http jndi url, e.g.
> http://localhost:8080/invoker/JNDIProxy
> then it should still be able to shutdown the server
> as long as it can obtain an MBeanServerConnection usable remotely.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 14:00:52 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 6 Jul 2009 14:00:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7074) some jars required
 by remote Profile Service clients are not included in client/ or
 client/jboss-clientall.jar
In-Reply-To: <631441563.1246562451433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <905805639.1246903252300.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475086#action_12475086 ] 

Ian Springer commented on JBAS-7074:
------------------------------------

Also missing from both client/ and jbossall-client.jar's MANIFEST.MF:

    lib/jboss-dependency.jar

Here's a stack trace from an exception thrown by a remote EJB PS client that does not have jboss-dependency.jar in its classpath:

java.lang.NoClassDefFoundError: org/jboss/dependency/spi/ControllerState
        at org.jboss.profileservice.spi.types.ControllerStateMetaType.<init>(ControllerStateMetaType.java:53)
        at org.jboss.profileservice.spi.types.ControllerStateMetaType.<clinit>(ControllerStateMetaType.java:49)
        at sun.misc.Unsafe.ensureClassInitialized(Native Method)
        at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
        at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
        at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
        at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
        at java.lang.reflect.Field.getLong(Field.java:528)
        at java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1614)
        at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52)
        at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:425)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:413)
        at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310)
        at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:547)
        at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583)
        at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.managed.plugins.DefaultFieldsImpl.readObject(DefaultFieldsImpl.java:381)
        at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.managed.plugins.ManagedPropertyImpl.readVersion1(ManagedPropertyImpl.java:663)
        at org.jboss.managed.plugins.ManagedPropertyImpl.readObject(ManagedPropertyImpl.java:633)
        at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at java.util.HashMap.readObject(HashMap.java:1030)
        at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.skipCustomData(ObjectInputStream.java:1912)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1874)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
        at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
        at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
        at $Proxy7.invoke(Unknown Source)
        at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
        at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
        at $Proxy4.getComponentsForType(Unknown Source)
        at test.Worker.run(Worker.java:44)
        at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.ClassNotFoundException: org.jboss.dependency.spi.ControllerState
        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:307)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
        ... 96 more


> some jars required by remote Profile Service clients are not included in client/ or client/jboss-clientall.jar
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7074
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7074
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The classes from the following jar are missing from jboss-clientall.jar and the jar itself is missing from client/:
>    common/lib/jboss-security-aspects.jar
> Its corresponding Maven artifact is org.jboss.aspects:jboss-security-aspects.
> If I find any others, I will update this JIRA.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 14:02:51 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 6 Jul 2009 14:02:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7074) some jars required
 by remote Profile Service clients are not included in client/ or
 client/jbossall-client.jar's Manifest classpath
In-Reply-To: <631441563.1246562451433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <815380177.1246903371467.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7074:
-------------------------------

        Summary: some jars required by remote Profile Service clients are not included in client/ or client/jbossall-client.jar's Manifest classpath  (was: some jars required by remote Profile Service clients are not included in client/ or client/jboss-clientall.jar)
    Description: 
The following jar is missing from client/jbossall-client.jar's Manifest classpath and from client/:

   common/lib/jboss-security-aspects.jar

Its corresponding Maven artifact is org.jboss.aspects:jboss-security-aspects.

If I find any others, I will update this JIRA.


  was:
The classes from the following jar are missing from jboss-clientall.jar and the jar itself is missing from client/:

   common/lib/jboss-security-aspects.jar

Its corresponding Maven artifact is org.jboss.aspects:jboss-security-aspects.

If I find any others, I will update this JIRA.




> some jars required by remote Profile Service clients are not included in client/ or client/jbossall-client.jar's Manifest classpath
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7074
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7074
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The following jar is missing from client/jbossall-client.jar's Manifest classpath and from client/:
>    common/lib/jboss-security-aspects.jar
> Its corresponding Maven artifact is org.jboss.aspects:jboss-security-aspects.
> If I find any others, I will update this JIRA.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 14:06:02 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 6 Jul 2009 14:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <432590158.1246903562960.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475087#action_12475087 ] 

Clebert Suconic commented on JBMESSAGING-1677:
----------------------------------------------



Can you provide some guide on how to build id please?


I have tried the regular paths such as mvn install:install, and it didn't work.

It was complaining about missing samples.jmstestLjmstest-listener:ejb:1.0


Thanks

> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Tim Fox
>         Attachments: JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

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

        


From jira-events at lists.jboss.org  Mon Jul  6 14:11:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 6 Jul 2009 14:11:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-106) SJC: Add support for
 property maps
Message-ID: <1148079522.1246903911428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC: Add support for property maps
----------------------------------

                 Key: JBJCA-106
                 URL: https://jira.jboss.org/jira/browse/JBJCA-106
             Project: JBoss JCA
          Issue Type: Task
          Components: Core
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Add support for property maps, so they can be passed in the configuration.

The remotable naming server is an example of an use-case.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 14:17:05 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 6 Jul 2009 14:17:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-107) SJC: Add support for
 a default value in system properties
Message-ID: <803321689.1246904225294.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC: Add support for a default value in system properties
---------------------------------------------------------

                 Key: JBJCA-107
                 URL: https://jira.jboss.org/jira/browse/JBJCA-107
             Project: JBoss JCA
          Issue Type: Task
          Components: Core
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Add support for a default in system properties like

 ${jboss.bind.address:localhost}


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

        


From jira-events at lists.jboss.org  Mon Jul  6 14:18:52 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Mon, 6 Jul 2009 14:18:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JGRP-1003) deadlock in TP.send
 - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1004131569.1246904332061.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Victor N reopened JGRP-1003:
----------------------------



Hi Bela,
another day, another bug :)

So... I have configured use_send_queues="true" for TCP. After some time I have got another strange situation - one of my servers was excluded from group and never rejoined. I looked into stack traces - I am sending you "jgroups_s1.txt" file by email, please look.

You will see one thread:

"Connection.Sender [server1:40001 - server2:33324],GateCluster,server1:40001" prio=10 tid=0x08f9d400 nid=0x147e waiting on condition [0x187d6000..0x187d7140]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x830c5d28> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358)
	at org.jgroups.blocks.TCPConnectionMap$TCPConnection$Sender.run(TCPConnectionMap.java:594)
	at java.lang.Thread.run(Thread.java:619)

This means that the thread is waiting until S ender's queue becomes non-empty (LinkedBlockingQueue.java:358):

while (count.get() == 0)
                    notEmpty.await();


But at the same time there are many threads like this (trying to send something to network):

"pool-2-thread-2" prio=10 tid=0x0891a000 nid=0x1f9d waiting on condition [0x20afe000..0x20aff0c0]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x63ac53e8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925)
	at java.util.concurrent.LinkedBlockingQueue.put(LinkedBlockingQueue.java:254)
	at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:429)
	at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)
	at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)
	at org.jgroups.protocols.TCP.send(TCP.java:53)
	at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)
	at org.jgroups.protocols.BasicTCP.sendToAllMembers(BasicTCP.java:126)
	at org.jgroups.protocols.TP.doSend(TP.java:1102)
	at org.jgroups.protocols.TP.access$1600(TP.java:52)
	at org.jgroups.protocols.TP$Bundler.sendBundledMessages(TP.java:1548)
	at org.jgroups.protocols.TP$Bundler.send(TP.java:1484)
	at org.jgroups.protocols.TP$Bundler.access$200(TP.java:1461)
	at org.jgroups.protocols.TP.send(TP.java:1077)
	at org.jgroups.protocols.TP.down(TP.java:907)
	at org.jgroups.protocols.Discovery.down(Discovery.java:363)
	at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)
	at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)
	at org.jgroups.protocols.FD.down(FD.java:327)
	at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)
	at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)
	at org.jgroups.protocols.pbcast.NAKACK.send(NAKACK.java:771)
	at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:572)
	at org.jgroups.protocols.UNICAST.down(UNICAST.java:468)
	at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:322)
	at org.jgroups.protocols.VIEW_SYNC.down(VIEW_SYNC.java:196)
	at org.jgroups.protocols.pbcast.GMS.down(GMS.java:939)
	at org.jgroups.protocols.FC.handleDownMessage(FC.java:617)
	at org.jgroups.protocols.FC.down(FC.java:434)
	at org.jgroups.protocols.FRAG2.down(FRAG2.java:158)
	at org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER.down(STREAMING_STATE_TRANSFER.java:275)
	at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:838)
	at org.jgroups.JChannel.down(JChannel.java:1504)
	at org.jgroups.JChannel.send(JChannel.java:670)
	at org.jgroups.JChannel.send(JChannel.java:686)
	at mytest.cluster.JGroupsClusterManagerImpl.doSendMessageToAllGates(JGroupsClusterManagerImpl.java:93)
	at mytest.cluster.JGroupsClusterManagerImpl.access$000(JGroupsClusterManagerImpl.java:24)
	at mytest.cluster.JGroupsClusterManagerImpl$1.run(JGroupsClusterManagerImpl.java:81)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)

This means that this 2nd thread is waiting until Sender's queue becomes non-full (LinkedBlockingQueue.java:254):

while (count.get() == capacity)
                    notFull.await();


How can this be at the same time - the same queue is empty and full?
Maybe there are 2 different instances of sender queue and 2 different senders? Is a new sender created in some situations (shunning, reconnect, etc.)?

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

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

        


From jira-events at lists.jboss.org  Mon Jul  6 14:20:51 2009
From: jira-events at lists.jboss.org (Naresh Bhatia (JIRA))
Date: Mon, 6 Jul 2009 14:20:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <796520070.1246904451820.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475090#action_12475090 ] 

Naresh Bhatia commented on JBMESSAGING-1677:
--------------------------------------------

I suspect that you are running mvn install in the jmstest-ear directory. Can you confirm if the same issue exists if you run mvn install in the parent directory (JmsTest)? That will make sure that all the dependencies are built before the EAR is built.

> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Tim Fox
>         Attachments: JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

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

        


From jira-events at lists.jboss.org  Mon Jul  6 14:24:51 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Mon, 6 Jul 2009 14:24:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <573757652.1246904691827.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475091#action_12475091 ] 

Victor N commented on JGRP-1003:
--------------------------------

Definitely, I am going to test with TCP_NIO ! I hope it does not need send queues and does not block in "send" call.

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

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

        


From jira-events at lists.jboss.org  Mon Jul  6 14:28:52 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 6 Jul 2009 14:28:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-108) SJC: Add support for
 <constructor>
Message-ID: <962038176.1246904932262.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC: Add support for <constructor>
----------------------------------

                 Key: JBJCA-108
                 URL: https://jira.jboss.org/jira/browse/JBJCA-108
             Project: JBoss JCA
          Issue Type: Task
          Components: Core
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Add support for <constructor> constructs for beans. 

An example

    <bean name="LookupPool">
        <constructor factoryMethod="newFixedThreadPool"  factoryClass="java.util.concurrent.Executors">
            <parameter>2</parameter>
        </constructor>
    </bean>


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

        


From jira-events at lists.jboss.org  Mon Jul  6 14:28:52 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 6 Jul 2009 14:28:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1599339048.1246904932654.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475093#action_12475093 ] 

Clebert Suconic commented on JBMESSAGING-1677:
----------------------------------------------

I had done that before.

anyway.. it worked when I removed my $HOME/.m2/repository



> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Tim Fox
>         Attachments: JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

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

        


From jira-events at lists.jboss.org  Mon Jul  6 14:39:04 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Mon, 6 Jul 2009 14:39:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7078) Create
 SSLSocketFactory that uses a JaasSecurityDomain
In-Reply-To: <565179297.1246891551731.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <334551484.1246905544032.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475098#action_12475098 ] 

Marcus Moyses commented on JBAS-7078:
-------------------------------------

More information:
http://www.jboss.org/community/wiki/JaasSecurityDomainSocketFactory

> Create SSLSocketFactory that uses a JaasSecurityDomain
> ------------------------------------------------------
>
>                 Key: JBAS-7078
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7078
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Marcus Moyses
>            Assignee: Marcus Moyses
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> We need a SSLSocketFactory with a default constructor and a static getDefault method that sets up SSL using a JaasSecurityDomain mbean so it can be used for LDAPS, Remoting, etc.
> The name of the security domain must be set as a system property.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 14:44:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 6 Jul 2009 14:44:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-109) Cobertura 1.9.2
Message-ID: <2038758232.1246905891403.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Cobertura 1.9.2
---------------

                 Key: JBJCA-109
                 URL: https://jira.jboss.org/jira/browse/JBJCA-109
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2




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

        


From jira-events at lists.jboss.org  Mon Jul  6 14:52:51 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 6 Jul 2009 14:52:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-131) OpenID Integration
Message-ID: <1207990758.1246906371307.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

OpenID Integration
------------------

                 Key: JBID-131
                 URL: https://jira.jboss.org/jira/browse/JBID-131
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1


Integrate Openid4Java which is ASL 2

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

        


From jira-events at lists.jboss.org  Mon Jul  6 15:18:51 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Mon, 6 Jul 2009 15:18:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-422) Allow
 LdapExtLoginModule to
 read the bind credential with an external command
Message-ID: <340822324.1246907931488.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Allow LdapExtLoginModule to read the bind credential with an external command
-----------------------------------------------------------------------------

                 Key: SECURITY-422
                 URL: https://jira.jboss.org/jira/browse/SECURITY-422
             Project: JBoss Security and Identity Management
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: JBossSecurity_2.0.3.SP2
            Reporter: Marcus Moyses
            Assignee: Marcus Moyses
             Fix For: JBossSecurity_2.0.3.SP2


The LdapExtLoginModule bust be able to read the bind credential password with an external command.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 15:24:51 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Mon, 6 Jul 2009 15:24:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (SECURITY-422) Allow
 LdapExtLoginModule to
 read the bind credential with an external command
In-Reply-To: <340822324.1246907931488.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <582599647.1246908291420.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcus Moyses resolved SECURITY-422.
------------------------------------

    Resolution: Done


Feature implemented. An example would be:

<module-option name="bindCredential">{EXT}cat mypassword</module-option>

> Allow LdapExtLoginModule to read the bind credential with an external command
> -----------------------------------------------------------------------------
>
>                 Key: SECURITY-422
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-422
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: JBossSecurity_2.0.3.SP2
>            Reporter: Marcus Moyses
>            Assignee: Marcus Moyses
>             Fix For: JBossSecurity_2.0.3.SP2
>
>
> The LdapExtLoginModule bust be able to read the bind credential password with an external command.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 15:41:51 2009
From: jira-events at lists.jboss.org (Rostyslav Smirnov (JIRA))
Date: Mon, 6 Jul 2009 15:41:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7079) Can't redirect root
 requests without ROOT.war
Message-ID: <1964202660.1246909311435.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Can't redirect root requests without ROOT.war
---------------------------------------------

                 Key: JBAS-7079
                 URL: https://jira.jboss.org/jira/browse/JBAS-7079
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Tomcat) service
    Affects Versions: JBossAS-5.1.0.GA
         Environment: Windows XP, JDK 1.6.0_14
            Reporter: Rostyslav Smirnov
            Assignee: Remy Maucherat


When ROOT.war is removed, root URL request always returns 404, ignoring URL rewrite rules.

Steps to reproduce:

1) Set up a single URL rewriting rule for jboss.web engine that redirects root requests:

RewriteRule ^/$ /admin-console/ [R]

At this point everything works and http://localhost:8080/ becomes http://localhost:8080/admin-console/

2) As the ROOT.war is now inaccessible, remove or rename it. Now http://localhost:8080/ just returns 404, ignoring the rule.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 16:14:51 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Mon, 6 Jul 2009 16:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7080) Add options to set
 providers and algorithms in the JaasSecurityDomain
Message-ID: <1841490058.1246911291396.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add options to set providers and algorithms in the JaasSecurityDomain
---------------------------------------------------------------------

                 Key: JBAS-7080
                 URL: https://jira.jboss.org/jira/browse/JBAS-7080
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Marcus Moyses
            Assignee: Marcus Moyses
             Fix For: JBossAS-5.2.0.Beta1


Need to add options to set the provider for the KeyStore, TrustStore, KeyManagerFactory and TrustManagerFactory.
Need to add options to set the algorithm for the KeyManagerFactory and TrustManagerFactory.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 16:16:55 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 6 Jul 2009 16:16:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1354336854.1246911415278.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBXB-206:
---------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242058


> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>            Assignee: Alexey Loubyansky
>         Attachments: jboss-profiler.properties, jbossxb.zip, server.log.gz
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 16:35:52 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Mon, 6 Jul 2009 16:35:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7080) Add options to set
 providers and algorithms in the JaasSecurityDomain
In-Reply-To: <1841490058.1246911291396.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <934579436.1246912552016.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcus Moyses resolved JBAS-7080.
---------------------------------

    Resolution: Done


The following options are now available:
KeyStoreProvider
KeyManagerFactoryProvider
TrustStoreProvider
TrustManagerFactoryProvider
KeyManagerFactoryAlgorithm
TrustManagerFactoryAlgorithm 

> Add options to set providers and algorithms in the JaasSecurityDomain
> ---------------------------------------------------------------------
>
>                 Key: JBAS-7080
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7080
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Marcus Moyses
>            Assignee: Marcus Moyses
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Need to add options to set the provider for the KeyStore, TrustStore, KeyManagerFactory and TrustManagerFactory.
> Need to add options to set the algorithm for the KeyManagerFactory and TrustManagerFactory.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 16:37:52 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 6 Jul 2009 16:37:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7081)
 ConcurrentModificationException
 when invoking 'stop' managed operation on Queue managed component
Message-ID: <1715358388.1246912672146.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

ConcurrentModificationException when invoking 'stop' managed operation on Queue managed component
-------------------------------------------------------------------------------------------------

                 Key: JBAS-7081
                 URL: https://jira.jboss.org/jira/browse/JBAS-7081
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Ian Springer
            Assignee: Scott M Stark
             Fix For: JBossAS-5.2.0.Beta1


Here's the stack trace:

Exception when invoking stop(): java.lang.reflect.UndeclaredThrowableException: Failed to invoke method 'stop' on component 'jboss.messaging.destination:name=ex
,service=Queue' with parameters [].
Exception in thread "Thread-28" java.lang.RuntimeException: javax.ejb.EJBException: java.util.ConcurrentModificationException
        at test.Worker.run(Worker.java:102)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.ejb.EJBException: java.util.ConcurrentModificationException
        at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:77)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
        at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
        at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
        at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
        at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
Caused by: java.util.ConcurrentModificationException
        at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
        at java.util.HashMap$EntryIterator.next(HashMap.java:834)
        at java.util.HashMap$EntryIterator.next(HashMap.java:832)
        at org.jboss.util.TimedCachePolicy.getValidKeys(TimedCachePolicy.java:364)
        at org.jboss.virtual.plugins.cache.IterableTimedVFSCache.findContext(IterableTimedVFSCache.java:65)
        at org.jboss.virtual.plugins.cache.CombinedVFSCache.findContext(CombinedVFSCache.java:116)
        at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:91)
        at org.jboss.virtual.VFS.getRoot(VFS.java:200)
        at org.jboss.profileservice.management.templates.JmsDestinationTemplate.applyTemplate(JmsDestinationTemplate.java:115)
        at org.jboss.profileservice.management.AbstractTemplateCreator.applyTemplate(AbstractTemplateCreator.java:99)
        at org.jboss.profileservice.management.ManagementViewImpl.applyTemplate(ManagementViewImpl.java:1362)
        at sun.reflect.GeneratedMethodAccessor449.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$3.applyTemplate(AOPProxy$3.java)
        at org.jboss.profileservice.ejb.SecureManagementView.applyTemplate(SecureManagementView.java:77)
        at sun.reflect.GeneratedMethodAccessor446.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
        at org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
        at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
        at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
        at sun.reflect.GeneratedMethodAccessor386.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
        at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_29585222.invoke(InvocationContextInterceptor_z_fillMet
hod_29585222.java)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
        at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_29585222.invoke(InvocationContextInterceptor_z_setup_295852
22.java)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
        at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
        at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
        at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
        at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$3.applyTemplate(AOPProxy$3.java)
        at org.jboss.profileservice.ejb.SecureManagementView.applyTemplate(SecureManagementView.java:77)
        at sun.reflect.GeneratedMethodAccessor446.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
        at org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
        at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
        at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
        at sun.reflect.GeneratedMethodAccessor386.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
        at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_29585222.invoke(InvocationContextInterceptor_z_fillMet
hod_29585222.java)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
        at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_29585222.invoke(InvocationContextInterceptor_z_setup_295852
22.java)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
        at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
        at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
        at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
        at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
        at $Proxy7.invoke(Unknown Source)
        at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
        at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
        at $Proxy4.applyTemplate(Unknown Source)
        at test.Worker.run(Worker.java:93)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
        at $Proxy7.invoke(Unknown Source)
        at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
        at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
        at $Proxy4.applyTemplate(Unknown Source)
        at test.Worker.run(Worker.java:93)
        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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 16:57:51 2009
From: jira-events at lists.jboss.org (denny Valliant (JIRA))
Date: Mon, 6 Jul 2009 16:57:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3248) JBoss
 xercesImpl.jar conflicts with xerces.jar within Ears/wars
Message-ID: <138358849.1246913871546.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475124#action_12475124 ] 

denny Valliant commented on JBAS-3248:
--------------------------------------

You can just delete the xercesImpl jar in the jasperserver/WEB-INF/lib folder and it will start fine.  Haven't done extensive testing with XML stuff to make sure there isn't something broken deep inside, but everything seems to work just dandy.

> JBoss xercesImpl.jar conflicts with xerces.jar within Ears/wars
> ---------------------------------------------------------------
>
>                 Key: JBAS-3248
>                 URL: https://jira.jboss.org/jira/browse/JBAS-3248
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading, Clustering
>    Affects Versions: JBossAS-4.0.3 SP1
>         Environment: Red Hat Enterprise Linux ES release 4;
> java version 1.5.0_06;
> JBoss in cluster mode
>            Reporter: Alan
>            Assignee: Scott M Stark
>
> I have an application (.war file) that uses a lib called xerces.jar located at .war /WEB-INF/lib directory. I run JBoss in cluster mode. So, after deploy, when I run my application, I got an exception with the xml libs. I guess it's a classloader problem. MY application tries to use the JBoss xml classes intead of it's own. I discovered the problem was with the xerces.jar and xercesImpl.jar because I deleted the line below from the <JBOSS_HOME>/bin/run.sh:
> -Djava.endorsed.dirs=...
> I searched for a solution and discovered jdk versions before 1.5 have a bug with xml, so I tried the solution above and all worked fine. Now my application use it's own xerces instead of JBoss xerces.
> I think my solution is a workaround. I would like to know if there is a better way to solve this problem. Is there ?
> The exception is below.
> Than you.
> Alan
> The exception:
> java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.apache.struts.actions.DispatchAction.perform(DispatchAction.java :236)
>         at org.apache.struts.action.ActionServlet.processActionPerform(ActionServlet.java:1787)
>         at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1586)
>         at org.apache.struts.action.ActionServlet.doPost (ActionServlet.java:510)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:252)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java :81)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>         at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke (CustomPrincipalValve.java:39)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
>         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java :407)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>         at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:105)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
>         at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket (PoolTcpEndpoint.java:527)
>         at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.VerifyError: (class: org/apache/soap/util/xml/XercesParserLiaison, method: read signature: (Ljava/lang/String;Ljava/io/Reader;)Lorg/w3c/dom/Document;) Incompatible object argument 
>  for function call
>         at org.apache.soap.rpc.Call.<init>(Call.java)
>         at org.apache.soap.rpc.Call.<init>(Call.java)
>         at com.attachmate.mcs.agent.impl.SOAPPackager.a(SOAPPackager.java )
> ...

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

        


From jira-events at lists.jboss.org  Mon Jul  6 20:51:51 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 6 Jul 2009 20:51:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <298403386.1246927911482.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-7032:
---------------------------------


John, I am able to reproduce the issue.  Let me continue to investigate the root cause.

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

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

        


From jira-events at lists.jboss.org  Mon Jul  6 21:38:51 2009
From: jira-events at lists.jboss.org (John Ament (JIRA))
Date: Mon, 6 Jul 2009 21:38:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <251433786.1246930731498.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475142#action_12475142 ] 

John Ament commented on JBAS-7032:
----------------------------------

It's funny that this got brought back up, I was about to update this as well.  After some playing with it, if I configure the server to enter a clustered environment, I can get it (admin-console.war) to deploy correctly but attempting to access it results in a no active conversation exception.  I've only been able to reproduce this with a webbeans deployment, I'm not sure about you.  From what I can tell, the fact that it's deploying is apparently a bug w/ the current webbeans ri which doesn't seem to work correctly in a clustered environment.  The no active conversation is a result of the webbeans deployer and filter taking higher precedence over the seam deployment (I verified by looking at the stack trace and seeing that the seam request was running through the webbeans filter, rather than the seam filter).  If you believe it's relevant, I'll post that stacktrace tomorrow.

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 02:01:51 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 7 Jul 2009 02:01:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1003) deadlock in TP.send
 - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2002041713.1246946511803.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1003:
---------------------------

    Attachment: stacktrace.txt


> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>         Attachments: stacktrace.txt
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

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

        


From jira-events at lists.jboss.org  Tue Jul  7 04:06:52 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Tue, 7 Jul 2009 04:06:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-105) SJC/RAdeployer: Add
 support for DTDs
In-Reply-To: <1880250736.1246887652072.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2011844206.1246954012093.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved JBJCA-105.
------------------------------

    Resolution: Done


> SJC/RAdeployer: Add support for DTDs
> ------------------------------------
>
>                 Key: JBJCA-105
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-105
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>   Original Estimate: 0 minutes
>  Remaining Estimate: 0 minutes
>
> Add dtd deployment into sjc deployer
> create this task for tacking this function. code commit r90827 should belong this task

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

        


From jira-events at lists.jboss.org  Tue Jul  7 04:06:51 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Tue, 7 Jul 2009 04:06:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-105) SJC/RAdeployer: Add
 support for DTDs
In-Reply-To: <1880250736.1246887652072.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <554233812.1246954011961.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang updated JBJCA-105:
-----------------------------

     Original Estimate: 0 minutes
    Remaining Estimate: 0 minutes
              Due Date: 07/Jul/09


> SJC/RAdeployer: Add support for DTDs
> ------------------------------------
>
>                 Key: JBJCA-105
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-105
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>   Original Estimate: 0 minutes
>  Remaining Estimate: 0 minutes
>
> Add dtd deployment into sjc deployer
> create this task for tacking this function. code commit r90827 should belong this task

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

        


From jira-events at lists.jboss.org  Tue Jul  7 07:39:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 07:39:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBRULES-2157) Outline problems
	in DRL editor
In-Reply-To: <930975006.1246966791446.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1589864955.1246966791564.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Neil Wallace deleted JBRULES-2157:
----------------------------------


> Outline problems in DRL editor
> ------------------------------
>
>                 Key: JBRULES-2157
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2157
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Neil Wallace
>            Assignee: Kris Verlaenen
>            Priority: Minor
>
> Two (possibly related) problems with the outline view in the DRL editor:
> *) Rules that are commented out via a multi-line comment (/* ... */) still appear in the outline.
> *) Clicking on the name of a rule highlights some text near that rule.  I assume it's supposed to highight the title of the rule, but it misses.  Same thing affects the imports.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 07:39:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 07:39:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2157) Outline problems
	in DRL editor
Message-ID: <930975006.1246966791446.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Outline problems in DRL editor
------------------------------

                 Key: JBRULES-2157
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2157
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse
    Affects Versions: 3.0.4
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
            Priority: Minor
             Fix For: 5.0.1.FINAL


Two (possibly related) problems with the outline view in the DRL editor:

*) Rules that are commented out via a multi-line comment (/* ... */) still appear in the outline.

*) Clicking on the name of a rule highlights some text near that rule.  I assume it's supposed to highight the title of the rule, but it misses.  Same thing affects the imports.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 07:42:04 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 07:42:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2158) CLONE -Outline
 problems in DRL editor
Message-ID: <1063571693.1246966924703.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Outline problems in DRL editor
-------------------------------------

                 Key: JBRULES-2158
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2158
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse
    Affects Versions: 3.0.4
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
            Priority: Minor
             Fix For: 5.0.1.FINAL


Two (possibly related) problems with the outline view in the DRL editor:

*) Rules that are commented out via a multi-line comment (/* ... */) still appear in the outline.

*) Clicking on the name of a rule highlights some text near that rule.  I assume it's supposed to highight the title of the rule, but it misses.  Same thing affects the imports.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 07:54:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 07:54:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2159) CLONE -DSL Parser
	"eval"
Message-ID: <2073094308.1246967691507.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -DSL Parser "eval"
------------------------

                 Key: JBRULES-2159
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2159
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler-DSL
    Affects Versions: 4.0.1
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
            Priority: Minor
             Fix For: 5.0.1.FINAL


rule "PatternTest"
       when
               $pli:Item( title matches "^Test\s*")
       then
                       #
end

this one compiles but on Runtime it ends in an Exception when title looks for example like this "BlaBla (Test)".

as workaround i thought about using the next part, but

rule "PatternTest"
       when
               $pli:Item( eval(title.matches("^Test\s*")) )
       then
                       #
end

it resolves into, also it shouldn't (because title.matches() is Java Code a shouldn't be parsed by the DSL Parser itself):

SyntaxfehlerRule Compilation error : [Rule name=OnlineStreaming Start,
agendaGroup=MAIN, salience=100, no-loop=true]
com/p7s1/swi/phoenix/n24/Rule_OnlineStreaming_Start_0.java (19:923) :
Invalid escape sequence (valid ones are \b \t \n \f \r \" \' \\ )

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

        


From jira-events at lists.jboss.org  Tue Jul  7 08:04:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 08:04:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2160) CLONE -Use of
 reserved word as bound variable in a pattern results as NPE
Message-ID: <1001322886.1246968291672.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Use of reserved word as bound variable in a pattern results as NPE
-------------------------------------------------------------------------

                 Key: JBRULES-2160
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2160
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 4.0.2
         Environment: Eclipse 3.2, Windows XP
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


example:

rule "This generates an NPE"
	when
		result : ReservedWordNPEFact(data < 15)
	then
		result.setData(new Integer(1));	 
end

At least in the eclipse IDE, this generates an NPE.  Change result to something like:


rule "This generates an NPE"
	when
		f: ReservedWordNPEFact(data < 15)
	then
		f.setData(new Integer(1));	 
end

and it goes away.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 08:15:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 08:15:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2161) CLONE -Prefix
 'and' and infix 'and' not interchangeable
Message-ID: <523039314.1246968951585.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Prefix 'and' and infix 'and' not interchangeable
-------------------------------------------------------

                 Key: JBRULES-2161
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2161
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 4.0.2
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


The documentation on the 'and' Conditional Element seems to imply that these constructs are equivalent:

		$p1:Entity($code1:code)
		not (and
			$p2:Entity(code == $code1)
			 eval(MyStaticClass.match($p1, $p2))
		)

		$p1:Entity($code1:code)
		not (
			$p2:Entity(code == $code1)
			and eval(MyStaticClass.match($p1, $p2))
		)

Actually, the first version crashes with this message:

unknown:93:7 Unexpected token 'and'[96,2]: unknown:96:2 mismatched token: [@792,3685:3685=')',<12>,96:2]; expecting type THEN

I'm on drools 4.0.2 and mvel14-1.2.8.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 08:27:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 08:27:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2162) CLONE -Issue in
 Drools 4.0.7 when run in Multithreaded environment
Message-ID: <1624228605.1246969671438.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Issue in Drools 4.0.7 when run in Multithreaded environment
------------------------------------------------------------------

                 Key: JBRULES-2162
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2162
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 4.0.7
         Environment: OS AIX 1.5
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


Hi 

We have a batch program(Informatica mapping) which uses Jars taken from an application which uses JBoss Drools 4.0.7 and MVEL 1.3.7. The informatica Integration service runs in AIX Machine with JRE Version 1.5. The batch program process millions of records which in turn calls the Drools API. To improve the performance, we tried running our informatica process in a multi threaded environment(4 threads). While running we got the following exception for every record that we process(across all the threads).



: Exception executing predicate eval( $terDate.before(ExtDateTimeUtils.getDate("01/01/1900")) )
	at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:216)
	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:318)
	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:145)
	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:318)
	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:162)
	at org.drools.reteoo.Rete.assertObject(Rete.java:175)
	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:192)
	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:71)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:911)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:883)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:684)
	at org.drools.reteoo.ReteooStatelessSession.execute(ReteooStatelessSession.java:160)
	at com.wellpoint.eps.epds.business.framework.rules.jbrules.JBRulesExecutor.fireAllRules(JBRulesExecutor.java:85)
	at com.wellpoint.eps.epds.business.framework.validation.BaseHandlerImpl.validateInternal(BaseHandlerImpl.java:141)
	at com.wellpoint.eps.epds.business.framework.validation.BaseHandlerImpl.validateInternal(BaseHandlerImpl.java:75)
	at com.wellpoint.eps.epds.business.framework.validation.AbstractBusinessRuleHandler.validate(AbstractBusinessRuleHandler.java:43)
	at com.wellpoint.eps.epds.business.application.validation.ProviderContractBusinessRuleHandler.validate(ProviderContractBusinessRuleHandler.java:43)
	at com.wellpoint.eps.epds.business.framework.service.DefaultRuleValidationServiceImpl.applyBusinessRules(DefaultRuleValidationServiceImpl.java:284)
	at com.eps.epds.api.validation.ValidationServiceDeligator$DefaultValidationServiceImpl.validate(ValidationServiceDeligator.java:181)
	at com.informatica.powercenter.server.jtx.JTXPartitionDriverImplGen.inputTransaction(JTXPartitionDriverImplGen.java:1414)
Caused by: org.mvel.CompileException: cannot invoke method
	at org.mvel.optimizers.impl.refl.MethodAccessor.getValue(MethodAccessor.java:54)
	at org.mvel.optimizers.impl.refl.VariableAccessor.getValue(VariableAccessor.java:39)
	at org.mvel.ast.VariableDeepPropertyNode.getReducedValueAccelerated(VariableDeepPropertyNode.java:22)
	at org.mvel.ast.PropertyASTNode.getReducedValueAccelerated(PropertyASTNode.java:21)
	at org.mvel.MVELRuntime.execute(MVELRuntime.java:90)
	at org.mvel.CompiledExpression.getValue(CompiledExpression.java:111)
	at org.mvel.MVEL.executeExpression(MVEL.java:235)
	at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:45)
	at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:209)
	... 20 more
Caused by: java.lang.reflect.InvocationTargetException
	at sun.reflect.GeneratedMethodAccessor45.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:615)
	at org.mvel.optimizers.impl.refl.MethodAccessor.getValue(MethodAccessor.java:46)
	... 28 more
Caused by: java.lang.NullPointerException
	at java.util.Date.getMillisOf(Date.java:953)
	at java.util.Date.before(Date.java:912)
	... 32 more
].




Could you please let me know if this is a known issue or is there any workaround for this problem?


Thanks
Sitaraman

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

        


From jira-events at lists.jboss.org  Tue Jul  7 08:35:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 08:35:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2163) CLONE -Exception
 when compiling a rule with "dialect mvel"
Message-ID: <904746940.1246970151549.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Exception when compiling a rule with "dialect mvel"
----------------------------------------------------------

                 Key: JBRULES-2163
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2163
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 5.0.0.M1
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


The following expression would compile without any problem with "dialect java":

new String[][]{{"2008-04-01", "2008-04-10"}}

But would generate a compiler error - "Unable to build expression...." with "dialect mvel".

Will upload an sample code to demonstrate this bug.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 08:37:51 2009
From: jira-events at lists.jboss.org (anil kumar (JIRA))
Date: Tue, 7 Jul 2009 08:37:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7082) <h:dataTable> with
 multiple column with single row is not working
Message-ID: <395228322.1246970271476.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

<h:dataTable> with multiple column with single row is not working
-----------------------------------------------------------------

                 Key: JBAS-7082
                 URL: https://jira.jboss.org/jira/browse/JBAS-7082
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.1.0.GA
         Environment: windows
            Reporter: anil kumar


  <h:dataTable id="advScreenConfigId" value="#{HeaderBean.records}" var="screenConfig" >  
           <h:column>               
                <h:outputText  value="#{screenConfig.displayTitle}"> </h:outputText> 
            </h:column>              
 </h:dataTable>

this {HeaderBean.records}, will generate some 6 records.These records are displaying one by one , now its showing in 6 rows. I want all these in single row. I tried using facet but didn't work . Please suggest me on this.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 08:40:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 08:40:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2164) CLONE
 -Serialization of
 working memories for rulebases with Accumulates are failing
Message-ID: <158778095.1246970451911.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Serialization of working memories for rulebases with Accumulates are failing
-----------------------------------------------------------------------------------

                 Key: JBRULES-2164
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2164
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  5.0.0.M2
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


Serialization of working memories with rules like this are failing:

rule "Test sum" salience 80
    dialect "java"
    when
    	$sum    : Number( doubleValue >= 10 ) 
    	                       from accumulate( Person( $likes : likes ) and Cheese( type == $likes, $price : price  ),
                                                sum( $price ) );
    then
        results.add( $sum );
end  



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

        


From jira-events at lists.jboss.org  Tue Jul  7 08:49:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 08:49:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2165) CLONE
 -RulebasePartitioningTest  test failure
Message-ID: <479040377.1246970991468.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -RulebasePartitioningTest  test failure
---------------------------------------------

                 Key: JBRULES-2165
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2165
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-guvnor
    Affects Versions:  5.0.0.M2
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


unit test failure when building MR2 source code 
This works if config.setMultithreadEvaluation( true ); line commented out

-------------------------------------------------------------------------------
Test set: org.drools.integrationtests.RulebasePartitioningTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.15 sec <<< FAILURE!
testRulebasePartitions1(org.drools.integrationtests.RulebasePartitioningTest)  Time elapsed: 0.14 sec  <<< FAILURE!
junit.framework.AssertionFailedError: expected:<3> but was:<0>
    at junit.framework.Assert.fail(Assert.java:47)
    at junit.framework.Assert.failNotEquals(Assert.java:282)
    at junit.framework.Assert.assertEquals(Assert.java:64)
    at junit.framework.Assert.assertEquals(Assert.java:201)
    at junit.framework.Assert.assertEquals(Assert.java:207)
    at org.drools.integrationtests.RulebasePartitioningTest.testRulebasePartitions1(RulebasePartitioningTest.java:82)

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

        


From jira-events at lists.jboss.org  Tue Jul  7 08:55:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 08:55:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2166) CLONE -Decimal
 numbers only
 works on locales that uses "." (dot) for decimal separator
Message-ID: <223861723.1246971351555.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Decimal numbers only works on locales that uses "." (dot) for decimal separator
--------------------------------------------------------------------------------------

                 Key: JBRULES-2166
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2166
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 5.0.0.M3
         Environment: Mac OS X 10.5.5 with default locale to Portuguese/Brazil
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
            Priority: Blocker
             Fix For: 5.0.1.FINAL


Test MiscTest.testExtends fails on my development environment. To ensure that it was a Locale problem i seted on top of this test case the US locale (Locale.setDefault(Locale.US);) and then the test worked.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 08:59:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 08:59:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2167) CLONE -Deadlock
 when RuleAgent
 thread refreshes rules while another thread creates a statefulSession
Message-ID: <1093288537.1246971591536.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Deadlock when RuleAgent thread refreshes rules while another thread creates a statefulSession
----------------------------------------------------------------------------------------------------

                 Key: JBRULES-2167
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2167
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 4.0.7
         Environment: Windows XP SP3
Sun JRE 1.5.0_14
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


I believe I have discovered a deadlock that can occur in drools 4.0.7 if the RuleAgent refreshes its associated RuleBase whilst a new stateful session is being created on the RuleBase by another thread. 

The thread dump below shows the deadlock where the two thread "Timer-15" and "DataSource(com.acme.Source)-2" are deadlocked. Thread "Timer-15" is the timer thread created by the RuleAgent rule refresh mechanism to check if the rules files have changed, and to refresh the rules when a change is found. If it finds changes to the rules then it obtains a lock (<0x189a8d88> (a java.util.HashMap)) and proceeds to removes the old version of the changed package from the RuleBase. To do this it needs to obtain another lock (<0x189a2ba0> (a org.drools.reteoo.ReteooRuleBase)) before it can call removeRule.

However, in another thread "DataSource(com.acme.Source)-2" a new stateful session is being created on the same RuleBase. This has already obtained the lock  (<0x189a8d88> (a java.util.HashMap)) that the Timer thread is waiting for, and is itself waiting for the another lock <0x189a2ba0> (a org.drools.reteoo.ReteooRuleBase) that the Timer thread has already locked, hence the deadlock.

In my own application I coded around this by eventually not using the RuleAgent in-built refresh mechanism, but instead periodically calling refreshRuleBase() on the RuleAgent in the SAME thread used to create the Stateful session, thus avoiding any deadlock.


"Timer-15" daemon prio=6 tid=0x02f4b0e8 nid=0x1864 waiting for monitor entry [0x038cf000..0x038cfa68]
	at org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:270)
	- waiting to lock <0x189a2ba0> (a org.drools.reteoo.ReteooRuleBase)
	at org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:656)
	at org.drools.common.AbstractRuleBase.removePackage(AbstractRuleBase.java:570)
	- locked <0x189a8d88> (a java.util.HashMap)
	at org.drools.agent.PackageProvider.removePackage(PackageProvider.java:45)
	at org.drools.agent.PackageProvider.applyChanges(PackageProvider.java:63)
	at org.drools.agent.RuleAgent.refreshRuleBase(RuleAgent.java:320)
	at org.drools.agent.RuleAgent$2.run(RuleAgent.java:438)
	at java.util.TimerThread.mainLoop(Unknown Source)
	at java.util.TimerThread.run(Unknown Source)



"DataSource(com.acme.Source)-2" daemon prio=4 tid=0x03027610 nid=0xfac waiting for monitor entry [0x0378f000..0x0378fb68]
	at org.drools.reteoo.ReteooRuleBase.newStatefulSession(ReteooRuleBase.java:225)
	- waiting to lock <0x189a8d88> (a java.util.HashMap)
	- locked <0x189a2ba0> (a org.drools.reteoo.ReteooRuleBase)
	at org.drools.common.AbstractRuleBase.newStatefulSession(AbstractRuleBase.java:284)
	at com.acme.RunRules.flush(RunRules.java:3337)
	at com.acme.ControlThread.run(ControlThread.java:465)
	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 09:08:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 09:08:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2168) CLONE
 -Deserializing a KnowledgeBase object throws a java.io.EOFException
Message-ID: <2122104211.1246972131431.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Deserializing a KnowledgeBase object throws a java.io.EOFException
-------------------------------------------------------------------------

                 Key: JBRULES-2168
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2168
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions:  5.0.0.M4, 5.0.0.M5
         Environment: Ubuntu 8.10
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


A java.io.EOFException is thrown when reading a serialized KnowledgeBase object from a file.

java.io.EOFException
	at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
	at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)
	at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
	at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:55)
	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:49)
	at org.drools.common.AbstractRuleBase.readExternal(AbstractRuleBase.java:227)
	at org.drools.reteoo.ReteooRuleBase.readExternal(ReteooRuleBase.java:173)
	at org.drools.impl.KnowledgeBaseImpl.readExternal(KnowledgeBaseImpl.java:83)
	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
	at com.sample.DroolsTest.read(DroolsTest.java:75)
	at com.sample.DroolsTest.testIO(DroolsTest.java:50)
	at com.sample.DroolsTest.main(DroolsTest.java:40)


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

        


From jira-events at lists.jboss.org  Tue Jul  7 09:14:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 09:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2169) CLONE -issue with
 using contains operator on array or collection of double (any )
Message-ID: <1932092042.1246972491518.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -issue with using contains operator on array or collection of double (any )
---------------------------------------------------------------------------------

                 Key: JBRULES-2169
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2169
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 4.0.7, 5.0.0.M3
         Environment: Windows XP service pack2
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


When using 'contains' operator on array or collection of strings its working fine. But when we use it for an array of primitive type double it gives a classcastexception . Is auto boxing not supported? May be this is fine as it mentioned in the documentation that it works only on Objects. I tried using the array of Double objects, here it doesn't throw an excpetion but the rule wasn't firing. The behaviour was same even if I use a collection of Double objects. 

 ex: 
using Array

     rule "OrderArray"
	 when

		 Order(valueArray contains 0)

	 then
             System.out.println("OrderArray");
end.

using Collection


 rule "OrderList"
	 when

		 Order(valueList contains 0)

	 then
             System.out.println("OrderList");
end.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 09:17:55 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 09:17:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2170) CLONE -Code
 completion in DSL in when-part does not work properly anymore
Message-ID: <1800180225.1246972675077.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Code completion in DSL in when-part does not work properly anymore
-------------------------------------------------------------------------

                 Key: JBRULES-2170
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2170
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse
    Affects Versions: 5.0.0.M5
         Environment: Eclipse 3.4, JRE 6u10, WinXP
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
             Fix For: 5.0.1.FINAL


When using the Code completion in an DSL-File-Editor in the when-part the completion does not work properly anymore.
It only shows up if you hit ALT-Space and have no character entered, so you can see the full list of "commands". But it's not possible to restrict that list using the beginning of a phrase.

In the then-part everything works find.

And it already worked in "when" using Drools 4.0.7 with Eclipse 3.3.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 09:25:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 09:25:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2171) CLONE -No access
 to context in a constraint
Message-ID: <1547387351.1246973151491.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -No access to context in a constraint
-------------------------------------------

                 Key: JBRULES-2171
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2171
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.0.M5
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
             Fix For: 5.0.1.FINAL


Say I have a class Job with a method isFinished() that returns boolean. Also in a process context, I have a variable "job" of the type "Job". In a constraint on a split node, the following happens:

a) When the constraint is in mvel dialect, the code "((Job)job).finished" is correct.
b) When the constraint is in Java dialect, the code "Job j = (Job)(context.getVariable("job"));" gets me the following compilation error:

Process Compilation error : org.drools.lang.descr.ProcessDescr at 48f675
	[omitted] (27:1248) : context cannot be resolved

The documentation of this is quite clear: "Code constraints are expressions that return a boolean value. They have access to the context variable. MVEL code constraints also have direct access to the variables."

Therefore I think this is a bug.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 09:29:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 09:29:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2172) CLONE -DSL can't
 support Chinese characters problem
Message-ID: <225731935.1246973391424.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -DSL can't  support Chinese characters problem
----------------------------------------------------

                 Key: JBRULES-2172
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2172
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: All
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


I from Shanghai China. My Drools version is Drools5 M5. 

I get some errors from Drools ide  when I use Chinese characters in dsl file and use it in dslr file.

I think support Chinese characters is very important,so i hope drools team can fix this bug in next Drools version.

Thanks.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 09:35:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 09:35:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2173) CLONE -Line break
 in DSL isnot generated anymore since Drools 5.0.0 CR1
Message-ID: <1749133183.1246973751893.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Line break in DSL isnot generated anymore since Drools 5.0.0 CR1
-----------------------------------------------------------------------

                 Key: JBRULES-2173
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2173
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 5.0.0.CR1
         Environment: jre6u12
eclipse 3.4
win xp
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


In Drools 4.0.7 and 5.0.0M5 it was possible to generate linebreaks using \n in an dsl-File.
Since 5.0.0 CR1 this is no longer possible: the \n is simply converted to the letter n which leads to compile-errors concerning the replaced code.

Example DSL:
# Test linebreak-bug since 5.0.0 CR1
[*][]only a simple test = System.out.println \n ("Did it generate a line break?");


Example DSLR:
#created on: 12.03.2009
package linebreak
expander linebreakbug.dsl
rule "line break bugtest"
  when
    #conditions
  then
  only a simple test
end


This leads to the line
System.out.println n ("Did it generate a line break?");


Maybe this bug is related to https://jira.jboss.org/jira/browse/JBRULES-1970 where the handling of #-Characters in DSL-Files had been fixed.

In my special case I'v got an workaround, but that's no workaround for anyone:
Using one DSLR I generate 2 Outputs:
a) using DSLR with dsl-file-A leads to "DLR"-Code: I don't need line breaks here (today, but maybe next month?)
   I don't care if the generated Code is nice or not and if the line is long or not.
   The code works and is executed by the rules-engine. Everything fine here.
  
b) using DSLR with dsl-file-B leads to programming-code in another programming-language. This Code is never executed in Drools, it is simply generated.
The result is taken an copied into the target-system. For that task I have written an own plugin that does that stuff and works like a little post-processor.
So my workaround is to use my own "keyword" $CRLF in an DSL-File and - after the generation that Drools does - replaced that with "\n".
Not where nice but simple...

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

        


From jira-events at lists.jboss.org  Tue Jul  7 09:43:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 7 Jul 2009 09:43:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1076368575.1246974231483.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBXB-206:
---------------------------------

    Attachment: server-2.log.gz


> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>            Assignee: Alexey Loubyansky
>         Attachments: jboss-profiler.properties, jbossxb.zip, server-2.log.gz, server.log.gz
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 09:50:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 09:50:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2174) CLONE -DRL-Viewer
 does not keep position if refocused
Message-ID: <704590176.1246974651522.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -DRL-Viewer does not keep position if refocused
-----------------------------------------------------

                 Key: JBRULES-2174
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2174
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse
    Affects Versions: 5.0.0.CR1
         Environment: jre6u12
eclipse 3.4
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
            Priority: Minor
             Fix For: 5.0.1.FINAL


Using eclispe and working with an DSLR-File that depends an DSL-file.
The DSLR-File is a FormEditor (Multiparteditor) with 2 tabs: first tab for editing, 2nd one the "DRL Viewer".
Each time you navigate away and refocus that "DRL Viewer"-tab once again (with mouseclick) that view repositions the text to top / line 1.
That's very annoying if you have a bigger rulefile (that's the normal case) in is not state of the art (therefore I think this is a bug and not a feature request).
The viewer should keep it's position.

Suggestion: only change to top of text if viewer-content is regenerated / changed.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 09:50:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 09:50:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2174) DRL-Viewer does
 not keep position if refocused
In-Reply-To: <704590176.1246974651522.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <663160494.1246974651607.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Neil Wallace updated JBRULES-2174:
----------------------------------

    Summary: DRL-Viewer does not keep position if refocused  (was: CLONE -DRL-Viewer does not keep position if refocused)


> DRL-Viewer does not keep position if refocused
> ----------------------------------------------
>
>                 Key: JBRULES-2174
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2174
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-eclipse
>    Affects Versions: 5.0.0.CR1
>         Environment: jre6u12
> eclipse 3.4
>            Reporter: Neil Wallace
>            Assignee: Kris Verlaenen
>            Priority: Minor
>             Fix For: 5.0.1.FINAL
>
>
> Using eclispe and working with an DSLR-File that depends an DSL-file.
> The DSLR-File is a FormEditor (Multiparteditor) with 2 tabs: first tab for editing, 2nd one the "DRL Viewer".
> Each time you navigate away and refocus that "DRL Viewer"-tab once again (with mouseclick) that view repositions the text to top / line 1.
> That's very annoying if you have a bigger rulefile (that's the normal case) in is not state of the art (therefore I think this is a bug and not a feature request).
> The viewer should keep it's position.
> Suggestion: only change to top of text if viewer-content is regenerated / changed.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 09:56:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 09:56:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2175) CLONE -Using the
 "from" syntax
 in the when clause when running the "Drools Application" in debug mode
 takes longer than normal.
Message-ID: <1782935958.1246975011513.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Using the "from" syntax in the when clause when running the "Drools Application" in debug mode takes longer than normal. 
--------------------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2175
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2175
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


Just adding "t : Object() from m.getClass" to the drools project created by eclipse causes "builder.addPackageFromDrl( source );" to take about 48 seconds. if the from clause is not there it takes about 4 seconds.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 10:00:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2176) CLONE -multibyte
 characters in dsl  fails with "no viable alternative at character"
Message-ID: <439005257.1246975251577.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -multibyte characters in dsl  fails with "no viable alternative at character"
-----------------------------------------------------------------------------------

                 Key: JBRULES-2176
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2176
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler-DSL
    Affects Versions: 5.0.0.M1,  5.0.0.M2, 5.0.0.M3,  5.0.0.M4, 5.0.0.M5, 5.0.0.CR1
         Environment: Drools 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


Drools compiler fails to compile DSLs containing multibyte characters in them, says "no viable alternative at character".

----------
line 3:6 no viable alternative at character '?'
line 3:7 no viable alternative at character '?'

java.lang.NullPointerException
	at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:451)
	at org.drools.reteoo.ReteooRuleBase.addPackage(ReteooRuleBase.java:481)
	at org.drools.compiler.MultibyteDSLTest.testMultibyteDSL(MultibyteDSLTest.java:20)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
----------

http://lists.jboss.org/pipermail/rules-users/2009-March/008293.html


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

        


From jira-events at lists.jboss.org  Tue Jul  7 10:05:03 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2177) CLONE -NPE in
 compiler for fact class  w/o getters/setters
Message-ID: <1674151502.1246975503378.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -NPE in compiler for fact class  w/o getters/setters
----------------------------------------------------------

                 Key: JBRULES-2177
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2177
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler (expert)
    Affects Versions: 5.0.0.CR1
         Environment: any
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


A class with missing getters and setters, e.g.:
 public class Command {
	protected String  ident;
	protected Code    code;
	protected boolean refused;
	protected String  reason;
    public Command( String id, Code c ){
    	ident = id;
    	code  = c;
    }
}

used in a rule pattern such as, e.g.:
rule cleanupRefused
    when
        $c : Command( $i : ident, refused == true, $r : reason )
    then
        # whatever
end 

causes a NPE in Declaration:239 due to Declaration.readAccessor == null

This should produce a compiler error message.

NOTICE: Javadoc on constructors of class Declaration is incorrect!


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

        


From jira-events at lists.jboss.org  Tue Jul  7 10:10:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:10:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2178) CLONE -Rule
 failes to compile in 5.0 March 20th SNAPSHOT. Compiles ok in 4.07
Message-ID: <1914585082.1246975851502.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Rule failes to compile in 5.0 March 20th SNAPSHOT. Compiles ok in 4.07
-----------------------------------------------------------------------------

                 Key: JBRULES-2178
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2178
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
         Environment: Win Xp sp3
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


Attached code generates the following output. I would expect both rules to compile w/o an error.

Start
Fails
Rule Compilation error : [Rule name='a.b']
        test/Rule_a_b_0.java (11:488) : The method insert(Main) is undefined for the type Rule_a_b_0

Works
Done


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

        


From jira-events at lists.jboss.org  Tue Jul  7 10:16:51 2009
From: jira-events at lists.jboss.org (Michal Bali (JIRA))
Date: Tue, 7 Jul 2009 10:16:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2179) better
 integration of ruleflow and AgendaFilter
Message-ID: <438666444.1246976211719.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

better integration of ruleflow and AgendaFilter
-----------------------------------------------

                 Key: JBRULES-2179
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2179
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-core  (expert)
    Affects Versions: 5.0.1.FINAL
            Reporter: Michal Bali
            Assignee: Mark Proctor
             Fix For: 5.1.0.M1
         Attachments: agendaFilterWithRuleflow.zip

Hi,
I am creating this issue so that it won't be lost. See this post for more information: http://lists.jboss.org/pipermail/rules-users/2009-May/009110.html

My original email with one reply message is pasted below:
--------------------------------------------------------------
If a rule is not allowed to fire by an AgendaFilter the whole ruleflow stops. 

I've created a small test case (attached). It contains:
 - one DRL file with one dummy rule that is in some ruleflow-group.
 - one RF file with three nodes ('start', 'ruleflow group' and 'end')
 - a program that starts the process, and calls fireAllRules with custom agenda filter.

Once the program is executed the ruleflow will stop inside the ruleflow-group. If I remove the agenda filter it works as expected (the ruleflow finishes).

Tested with Drools 5.0.1.

Best regards,
Michal
----------------------------------------
Final reply from Mark:
It seems like a reasonable request, that if all the rules have been cancelled, fired or filtered that the ruleflow-group should be de-activated so the flow can continue. We'll look into it for 5.1.
---------------------------------------

Thanking you in advance,
Michal

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

        


From jira-events at lists.jboss.org  Tue Jul  7 10:16:51 2009
From: jira-events at lists.jboss.org (Michal Bali (JIRA))
Date: Tue, 7 Jul 2009 10:16:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2179) better
 integration of ruleflow and AgendaFilter
In-Reply-To: <438666444.1246976211719.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <225468721.1246976211865.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michal Bali updated JBRULES-2179:
---------------------------------

    Attachment: agendaFilterWithRuleflow.zip


Attaching the original test case.

> better integration of ruleflow and AgendaFilter
> -----------------------------------------------
>
>                 Key: JBRULES-2179
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2179
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Michal Bali
>            Assignee: Mark Proctor
>             Fix For: 5.1.0.M1
>
>         Attachments: agendaFilterWithRuleflow.zip
>
>
> Hi,
> I am creating this issue so that it won't be lost. See this post for more information: http://lists.jboss.org/pipermail/rules-users/2009-May/009110.html
> My original email with one reply message is pasted below:
> --------------------------------------------------------------
> If a rule is not allowed to fire by an AgendaFilter the whole ruleflow stops. 
> I've created a small test case (attached). It contains:
>  - one DRL file with one dummy rule that is in some ruleflow-group.
>  - one RF file with three nodes ('start', 'ruleflow group' and 'end')
>  - a program that starts the process, and calls fireAllRules with custom agenda filter.
> Once the program is executed the ruleflow will stop inside the ruleflow-group. If I remove the agenda filter it works as expected (the ruleflow finishes).
> Tested with Drools 5.0.1.
> Best regards,
> Michal
> ----------------------------------------
> Final reply from Mark:
> It seems like a reasonable request, that if all the rules have been cancelled, fired or filtered that the ruleflow-group should be de-activated so the flow can continue. We'll look into it for 5.1.
> ---------------------------------------
> Thanking you in advance,
> Michal

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

        


From jira-events at lists.jboss.org  Tue Jul  7 10:22:52 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:22:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2180) CLONE -Default
 Guvnor
 repository path in Eclipse webdav plugin differs from Guvnors actual path.
Message-ID: <1346048272.1246976572007.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Default Guvnor repository path in Eclipse webdav plugin differs from Guvnors actual path.
------------------------------------------------------------------------------------------------

                 Key: JBRULES-2180
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2180
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse, drools-guvnor
    Affects Versions: 5.0.0.CR1
         Environment: Windows XP SP3 with Sun JDK 1.5.0_15. Eclipse Version: 3.4.1 Build id: M20080911-1700. Note that the Guvnor was running under JBoss AS 4.2.2.
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
             Fix For: 5.0.1.FINAL


This isn't really a bug, but more of a configuration issue.

The default repository location displayed by the "Guvnor Repository Location" wizard in Eclipse is not the default location used by the Guvnor distributed under the drools project. Consequently, if you accept the default value in the wizard, it is likely you will not be able to connect to the repository running under the Guvnor. The default repository location in the wizard is:

    /jboss-brms/org.drools.guvnor.Guvnor/webdav

However, the default location to connect to the drools Guvnor is:

   /drools-guvnor/org.drools.guvnor.Guvnor/webdav

as the default URL for the Guvnor is: 

   http://localhost:8080/drools-guvnor/org.drools.guvnor.Guvnor/Guvnor.html

It is not obvious at first what is wrong, as if you accept the default repository location then the new location appears in the Guvnor Repositories view. But when you click on this repository name to browse it you get the following error:

"Server not reachable"

I initially assumed it was a network issue, or the wrong port (8080) etc. Only after careful inspection is it obvious that the default repository location in the Eclipse wizard does not match the default URL used by the drools Guvnor.

There has been some discussion related to this under the JIRA GUVNOR-120, but I'm not sure if there is a conflict between the solution suggested in that JIRA and the issue raised here.


To Reproduce Problem
============================

This assumes that the Guvnor is running locally at localhost:8080 which is the default location "out of the box".

1. Link to the Guvnor by selecting the menu option to run the "Guvnor Repository Location" wizard: File, New, Other, Guvnor, Guvnor Repository Location.

2. I accepted the defaults, adding only user and password:

Location: localhost
Port: 8080
Repository: /jboss-brms/org.drools.guvnor.Guvnor/webdav
User Name: admin
Password: admin
Selected to save password

Click Finish and the link is created successfully in the "Guvnor Repositories" view as:

http://localhost:8080/jboss-brms/org.drools.guvnor.Guvnor/webdav

3. Click on the link above. This causes the following error:

   "Server not reachable"

Notice that the URL for the link says jboss-brms instead of drools-guvnor.

4. Delete the link you just created and perform steps 1 and 2 again, but this time set the Repository value in step 2 as:

/drools-guvnor/org.drools.guvnor.Guvnor/webdav

5. Click on the new link above. This should allow you to browse the repository on the Guvnor side correctly.



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

        


From jira-events at lists.jboss.org  Tue Jul  7 10:28:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:28:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2181) CLONE -Race
 conditions in AbstractRuleBase
Message-ID: <1783558499.1246976931541.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Race conditions in AbstractRuleBase
------------------------------------------

                 Key: JBRULES-2181
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2181
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core  (expert)
    Affects Versions: 5.0.0.CR1
         Environment: Windows, Drools CR1
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


ReteooRuleBaseMultiThreadedTest is failing because of race conditions in AbstractRuleBase

java.lang.NullPointerException
	at org.drools.common.AbstractRuleBase.lock(AbstractRuleBase.java:408)
	at org.drools.common.AbstractRuleBase.removePackage(AbstractRuleBase.java:655)
	at org.drools.reteoo.ReteooRuleBaseMultiThreadedTest$PackageModifier.doOperation(ReteooRuleBaseMultiThreadedTest.java:143)
	at org.drools.reteoo.ReteooRuleBaseMultiThreadedTest$BlockedThread.run(ReteooRuleBaseMultiThreadedTest.java:121)

junit.framework.AssertionFailedError: Exception in modifier thread expected:<false> but was:<true>
	at org.drools.reteoo.ReteooRuleBaseMultiThreadedTest.testNewSessionWhileModifyingRuleBase(ReteooRuleBaseMultiThreadedTest.java:80)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 10:32:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:32:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2182) CLONE -Problems
 with persistence of processes
Message-ID: <1709947390.1246977171747.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Problems with persistence of processes
---------------------------------------------

                 Key: JBRULES-2182
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2182
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core (flow)
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
             Fix For: 5.0.1.FINAL


Unmarshalling of persisted process instances containing variables failing.
Marshalling / unmarshalling or process instances as part of the session also does not use the pluggable process instance marshallers.
Working memory on unmarshalled process instances not set correctly.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 10:36:52 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:36:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2183) CLONE -XOR Split
 not working properly inside CompositeNode
Message-ID: <832865011.1246977412514.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -XOR Split not working properly inside CompositeNode
----------------------------------------------------------

                 Key: JBRULES-2183
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2183
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core (flow)
    Affects Versions: 5.0.0.M5, 5.0.0.CR1
         Environment: java.version = 1.6.0_11
java.vm.name = Java HotSpot(TM) Client VM
Windows Vista Service Pack 1
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
             Fix For: 5.0.1.FINAL



If XOR Split node is used inside CompositeNode the following exception occurs regardless of the fact that at least one outgoing condition _is_ fulfilled:

java.lang.IllegalArgumentException: XOR split could not find at least one valid outgoing connection for split Split
	at org.drools.workflow.instance.node.SplitInstance.internalTrigger(SplitInstance.java:72)
	at org.drools.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:111)
	at org.drools.workflow.instance.impl.NodeInstanceImpl.triggerConnection(NodeInstanceImpl.java:141)
	at org.drools.workflow.instance.impl.NodeInstanceImpl.triggerCompleted(NodeInstanceImpl.java:128)
	at org.drools.workflow.instance.node.ActionNodeInstance.triggerCompleted(ActionNodeInstance.java:62)
	at org.drools.workflow.instance.node.ActionNodeInstance.internalTrigger(ActionNodeInstance.java:58)
	at org.drools.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:111)

The accompanying attachment 'drools-xor-bug.zip' contains an example that reproduces the problem. 

Zip file contains the eclipse project - simply import it in Eclipse and run com.sample.RuleFlowTest.java.

There are two .rf files. normalXOR.rf contains a working process, using XOR Split outside of CompositeNode. weirdXOR.rf contains the same XOR Split branching and outgoing constraints, but is positioned within CompositeNode.

RuleFlowTest first successfully executes normalXOR flow, then fails while executing weirdXOR flow.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 10:40:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:40:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2184) CLONE -Update
 causes query to return no results
Message-ID: <1502951677.1246977651732.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Update causes query to return no results
-----------------------------------------------

                 Key: JBRULES-2184
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2184
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


I've found a weird scenario where a simple query which is returning the correct data, stops returning anything if you invoke update on one of the facts that it depends on.  If you use retract/insert instead of update then it works fine.  The problem only seems to occur if there is an inheritance relationship between the objects in the query.  

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

        


From jira-events at lists.jboss.org  Tue Jul  7 10:44:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:44:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2185) CLONE -Collection
 returned by
 StatefulKnowledgeSession.getObjects() doesn't conform to standard
 collection behaviour
Message-ID: <1930341947.1246977891526.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Collection returned by StatefulKnowledgeSession.getObjects() doesn't conform to standard collection behaviour
--------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2185
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2185
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


StatefulKnowledgeSession.getObjects() returns a collection containing the objects in working memory.

The Javadoc for Collection.contains says:

"Returns true if this collection contains the specified element. More formally, returns true if and only if this collection contains at least one element e such that (o==null ? e==null : o.equals(e)). "

This is not the case though for StatefulKnowledgeSessionImpl.ObjectStoreWrapper.  The implementation of contains returns true only if it is the exact same object instance, but false if it is a different instance but which equals the instance in the working memory.

A workaround is to create a new collection and put the items returned into that.


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

        


From jira-events at lists.jboss.org  Tue Jul  7 10:50:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:50:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2186) CLONE
 -declaration of 2
 variables in the init part of accumulate is not possible
Message-ID: <220881410.1246978251476.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -declaration of 2 variables in the init part of accumulate is not possible
--------------------------------------------------------------------------------

                 Key: JBRULES-2186
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2186
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


Take a rule with 2 variables int the init part, like
		$maxCa:CompanyCA() from accumulate($ca:CompanyCA($year:year) from $p.cas, 
										init(ecrm.party.CompanyCA currentCA=null;int maxYear = 0;),
										action(maxYear = Math.max(maxYear, $year);),
										result(currentCA)); 
which can return the year and the ca where the ca is max.

It won't compile with the error that company CA is not declare.

The bug is in the class org.drools.rule.builder.dialect.java.JavaAccumulateBuilder
line 194
            int index = 0;
            for ( Iterator it = initCodeAnalysis.getLocalVariablesMap().entrySet().iterator(); it.hasNext(); ) {
                Map.Entry entry = (Map.Entry) it.next();
                attributes[index] = (String) entry.getKey();
                attributesTypes[index] = ((JavaLocalDeclarationDescr) entry.getValue()).getType();
            }
when the variables are put in the context, only the first is put (index stay at 0)

We should increment the index
            int index = 0;
            for ( Iterator it = initCodeAnalysis.getLocalVariablesMap().entrySet().iterator(); it.hasNext(); ) {
                Map.Entry entry = (Map.Entry) it.next();
                attributes[index] = (String) entry.getKey();
                attributesTypes[index] = ((JavaLocalDeclarationDescr) entry.getValue()).getType();
                index ++;
            }









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

        


From jira-events at lists.jboss.org  Tue Jul  7 10:54:55 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:54:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2187) CLONE -Unusable
 error message
 during test scnario execution: Exception executing predicate
 org.drools.base.mvel.MVELPredicateExpression@739c6e
Message-ID: <1008630844.1246978495815.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Unusable error message during test scnario execution: Exception executing predicate org.drools.base.mvel.MVELPredicateExpression at 739c6e
----------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2187
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2187
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-guvnor
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Mark Proctor
            Priority: Minor
             Fix For: 5.0.1.FINAL


With Guvnor 5.0.0.CR1 it seems that I have produced an error in a decision table which only appears during test scenario execution.
However the error message given in the browser (and on the console) is not very helpful:
{code}
2009-04-17 15:31:28,691 INFO  [STDOUT] ERROR 17-04 15:31:28,690 (ServiceImplementation.java:runScenario:1875)    org.drools.RuntimeDroolsException: Exception executing predicate org.drools.base.mvel.MVELPredicateExpression
{code}

As far as I know it's possible to extract the actual expression from MVELPredicateExpression and it would be nice if this gets printed so that users have a chance of fixing the problem. ;-)

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

        


From jira-events at lists.jboss.org  Tue Jul  7 10:54:58 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 7 Jul 2009 10:54:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7052) when invoked from
 remote
 client, call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <783570980.1246978498264.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475222#action_12475222 ] 

Scott Marlow commented on JBAS-7052:
------------------------------------

Ian, this jira is not assigned to me but I wanted to try helping with a few questions.

I read the above jira information and am left wondering a few things.  I assume that you already put in effort to resolve this on your own, so please help me answer these questions:

1.  Does the above exception occur after the server side getComponentsForType() has been invoked?  I assume yes and that this is caused by the handling of the getComponentsForType() result object being returned.

2.  Assuming that this is caused by the result value from the getComponentsForType(), what classes are being returned?  

3.  If you know, can you tell me why the org.jboss.profileservice.management.ManagedOperationDelegate class is being referenced in the above call stack?  

> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

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

        


From jira-events at lists.jboss.org  Tue Jul  7 10:58:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:58:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2188) CLONE -MVEL
 consequences + modify call == NPE
Message-ID: <1921784687.1246978731623.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -MVEL consequences + modify call == NPE
---------------------------------------------

                 Key: JBRULES-2188
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2188
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


PetStore example is raising NPE because of a rule with MVEL dialect that contains a modify() call in the consequence.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 11:09:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:09:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2189) CLONE -MVEL debug
 not working anymore
Message-ID: <521726479.1246979391872.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -MVEL debug not working anymore
-------------------------------------

                 Key: JBRULES-2189
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2189
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
             Fix For: 5.0.1.FINAL


When debugging rules using the MVEL dialect, Eclipse cannot find the right MVEL source and line number to show when encountering a breakpoint in MVEL code.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 11:13:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:13:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2190) CLONE -Decision
 table web editor does not remember column configuration
Message-ID: <822610486.1246979631859.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Decision table web editor does not remember column configuration
-----------------------------------------------------------------------

                 Key: JBRULES-2190
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2190
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-guvnor
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Michael Neale
            Priority: Minor
             Fix For: 5.0.1.FINAL


When reconfiguring columns  (grouping, sorting, hiding of columns)in the guided/ web decision table editor, this configuration is lost if that editor is closed.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 11:17:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2191) CLONE
 -update(fact) doesn't work in ruleflow
Message-ID: <1018830665.1246979871500.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -update(fact) doesn't work in ruleflow
--------------------------------------------

                 Key: JBRULES-2191
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2191
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core  (expert), drools-core (flow)
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
            Priority: Critical
             Fix For: 5.0.1.FINAL


Hi,
org.drools.base.DefaultKnowledgeHelper uses newly added identityMap to keep track of fact handles. It looks like this identityMap is updated before a rule's consequence is called. However it is not updated before a Drools Flow on-exit action. This means that calling update(someFact) in a on-exit ruleflow action causes exception ("org.drools.FactException: Update error: handle not found for object: XXXXX. Is it in the working memory?"). 

this was tested on drools-core-5.0.0.20090417.044049-485.jar

Thanking you in advance.
Best Regards,
Michal


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

        


From jira-events at lists.jboss.org  Tue Jul  7 11:22:03 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2192) CLONE -Eclipse
 regression for MVEL debugging
Message-ID: <1685295764.1246980123767.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Eclipse regression for MVEL debugging
--------------------------------------------

                 Key: JBRULES-2192
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2192
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse (expert)
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


probably relate to an MVEL change.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 11:25:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:25:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2193) CLONE -Modify
 raises NPE when using "from"
Message-ID: <1318734644.1246980351600.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Modify raises NPE when using "from"
------------------------------------------

                 Key: JBRULES-2193
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2193
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


The attached file should generate everyting into a subdirectory ./movie and compile and execute.

You'll have to modify the classpath, though.

Regards
-W


# Shell this file to create subdir movie with *.java, Movie.drl, database.xml
#
# you'll have to modify the classpath setting - see below
#

mkdir movie || true

cat <<'TheEnd' >movie/Main.java
package movie;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.InputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.OutputStream;
import java.util.Collection;

import javax.xml.bind.JAXBContext;

import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderError;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.builder.ResourceType;
import org.drools.definition.KnowledgePackage;
import org.drools.io.ResourceFactory;
import org.drools.runtime.StatefulKnowledgeSession;

import javax.xml.bind.Unmarshaller;

public class Main {

       private StatefulKnowledgeSession session;

       public Main(){
       }

       public void init() throws Exception {

       KnowledgeBase kBase = KnowledgeBaseFactory.newKnowledgeBase();
       KnowledgeBuilder kBuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
       kBuilder.add( ResourceFactory.newFileResource( "movie/Movie.drl" ),
                     ResourceType.DRL );
       if( kBuilder.hasErrors() ){
               for( KnowledgeBuilderError err: kBuilder.getErrors() ){
                       System.out.println( err.toString() );
               }
               throw new IllegalStateException( "DRL errors" );
       }

       kBase.addKnowledgePackages( kBuilder.getKnowledgePackages() );

               File xml = new File( "database.xml" );
               JAXBContext jc = JAXBContext.newInstance( Database.class );
               Unmarshaller u = jc.createUnmarshaller();
               InputStream inputStream = new FileInputStream( xml );
               Database db = (Database)u.unmarshal( inputStream );
               inputStream.close();

       session = kBase.newStatefulKnowledgeSession();

               for( Movie m: db.getMovie() ){
                       session.insert( m );
               }
               for( Actor a: db.getActor() ){
                       session.insert( a );
               }
               for( Role r: db.getRole() ){
                       session.insert( r );
               }
               session.fireAllRules();
       }

       public static void main( String[] args ) throws Exception {
               Main rf = new Main();
               rf.init();
       }

}
TheEnd

cat <<'TheEnd' >movie/Role.java
package movie;

import javax.xml.bind.annotation.XmlAttribute;

public class Role implements Item {

       private String actor;
       private String movie;

       public Role(){
       }

       @XmlAttribute
       public String getActor() {
               return actor;
       }

       public void setActor(String actor) {
               this.actor = actor;
       }

       @XmlAttribute
       public String getMovie() {
               return movie;
       }

       public void setMovie(String movie) {
               this.movie = movie;
       }

       @Override
       public String toString(){
               return actor + " plays in " + movie;
       }

}
TheEnd

cat <<'TheEnd' >movie/Movie.java
package movie;

import java.util.HashSet;
import java.util.Set;
import javax.xml.bind.annotation.XmlAttribute;

public class Movie implements Item {
       private String title;
       private Set<Actor> cast;

       public Movie(){
       }

       @XmlAttribute
       public String getTitle() {
               return title;
       }
       public void setTitle(String title) {
               this.title = title;
       }

       public Set<Actor> getCast(){
               if( cast == null ) cast = new HashSet<Actor>();
               return cast;
       }

       @Override
       public int hashCode(){
               return title.hashCode();
       }

       @Override
       public boolean equals( Object o ){
               if( ! (o instanceof Movie ) ) return false;
               return this.title.equals( ((Movie)o).getTitle() );
       }

       @Override
       public String toString(){
               StringBuilder sb = new StringBuilder();
               sb.append( title ).append( "\n" );
               for( Actor a: getCast() ){
                       sb.append( "  " ).append( a.getName() ).append( "\n" );
               }
               return sb.toString();
       }
}
TheEnd

cat <<'TheEnd' >movie/Item.java
package movie;

/**
 * Marker interface for WMEs
 * @author Wolfgang Laun
 */
public interface Item {
}
TheEnd

cat <<'TheEnd' >movie/Database.java
package movie;

import java.util.ArrayList;
import java.util.List;

import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;

@XmlRootElement
@XmlType(propOrder={"movie", "actor" , "role" })
public class Database {

       private List<Movie> movie;
       private List<Actor> actor;
       private List<Role> role;

       public Database(){
       }

       @XmlElement
       public List<Movie> getMovie() {
               if( movie == null ) movie = new ArrayList<Movie>();
               return movie;
       }

       @XmlElement
       public List<Actor> getActor() {
               if( actor == null ) actor = new ArrayList<Actor>();
               return actor;
       }

       @XmlElement
       public List<Role> getRole() {
               if( role == null ) role = new ArrayList<Role>();
               return role;
       }

}
TheEnd

cat <<'TheEnd' >movie/Actor.java
package movie;

import java.util.ArrayList;
import java.util.List;
import javax.xml.bind.annotation.XmlAttribute;

public class Actor implements Item {

       private String name;
       private List<Movie> movies;

       public Actor(){
       }

       @XmlAttribute
       public String getName() {
               return name;
       }
       public void setName(String name) {
               this.name = name;
       }

       public List<Movie> getMovies(){
               if( movies == null ) movies = new ArrayList<Movie>();
               return movies;
       }

       @Override
       public String toString(){
               StringBuilder sb = new StringBuilder();
               sb.append( name ).append( "\n" );
               for( Movie m: getMovies() ){
                       sb.append( "  " ).append( m.getTitle() ).append( "\n" );
               }
               return sb.toString();
       }

       @Override
       public int hashCode(){
               return name.hashCode();
       }

       @Override
       public boolean equals( Object o ){
               if( ! (o instanceof Actor ) ) return false;
               return this.name.equals( ((Actor)o).getName() );
       }
}
TheEnd

cat <<'TheEnd' >movie/Movie.drl
package movie;

/***
 - List<?> as fact field type
 - Set<?> as fact field type
 - Match WMEs with elements from field with List<?> type: from
 - inline eval() for determining membership in Collection()
 - Write rules for a set of WME types using a "marker" interface.

*/

#
# Fill the Movies' cast lists with data from Role.
#
rule fillCast
   salience 100
   when
       $r : Role( $actor : actor, $movie : movie )
       $a : Actor( name == $actor )
       $m : Movie( title == $movie )
   then
       modify( $m ){
           getCast().add( $a );
       }
       retract( $r );
end

#
# Fill the Actors' list of movies with data from a Movie's cast list
#
rule fillMovies
   salience 90
   when
       $m : Movie( $cast : cast )
       $a : Actor() from $cast
   then
       System.out.println( "movie " + $m.getTitle() + " actor " + $a.getName() );
       modify( $a ){
           getMovies().add( $m );
       }
end

#
# Find a movie where HB and LB are in together
#
rule findHBLB
   when
       $hb : Actor( name == "Humphrey Bogart" )
       $lb : Actor( name == "Lauren Bacall" )
       $m : Movie( $title : title, $cast : cast, eval( $cast.contains( $hb ) && $cast.contains( $lb ) ) )
   then
       System.out.println( "HB & LB together in " + $title );
end

#
# Display any WME
#
rule showItem
   salience -100
   when
       $i : Item()
   then
       System.out.println( $i.toString() );
end
TheEnd

cat <<'TheEnd' >database.xml
<?xml version="1.0" encoding="UTF-8"?>
<database>
<movie title="Casablanca"/>
<movie title="Key Largo"/>
<movie title="To Have and Have Not"/>
<movie title="The African Queen"/>
<actor name="Humphrey Bogart"/>
<actor name="Katherine Hepburn"/>
<actor name="Ingrid Bergman"/>
<actor name="Lauren Bacall"/>
<role actor="Humphrey Bogart" movie="Casablanca"/>
<role actor="Ingrid Bergman"  movie="Casablanca"/>
<role actor="Humphrey Bogart" movie="The African Queen"/>
<role actor="Humphrey Bogart" movie="Key Largo"/>
<role actor="Humphrey Bogart" movie="To Have and Have Not"/>
<role actor="Lauren Bacall" movie="To Have and Have Not"/>
<role actor="Lauren Bacall" movie="Key Largo"/>
<role actor="Katherine Hepburn" movie="The African Queen"/>
</database>
TheEnd

export CLASSPATH=.:/extra/Drools-5.0.1.SNAPSHOT/drools-core.jar:/extra/Drools-5.0.1.SNAPSHOT/drools-api.jar:/extra/Drools-5.0.1.SNAPSHOT/drools-compiler.jar:/extra/Drools-5.0.1.SNAPSHOT/drools-ant.jar:/extra/Drools-5.0.1.SNAPSHOT/antlr-runtime.jar:/usr/local/eclipse/plugins/org.eclipse.jdt.core_3.4.4.v_894_R34x.jar:/extra/Drools-5.0.0.CR1/bin/lib/mvel2-2.0.8pre1.jar

javac movie/*.java

java movie/Main

cat <<'TheEnd'

#
# This is what I get:
#

movie Casablanca actor Ingrid Bergman
Exception in thread "main" org.drools.runtime.rule.ConsequenceException: java.lang.NullPointerException
       at org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:23)
       at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:943)
       at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:885)
       at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1086)
       at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:682)
       at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:649)
       at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:183)
       at movie.Main.init(Main.java:65)
       at movie.Main.main(Main.java:70)
Caused by: java.lang.NullPointerException
       at org.drools.base.DefaultKnowledgeHelper.modifyRetract(DefaultKnowledgeHelper.java:190)
       at movie.Rule_fillMovies_0.consequence(Rule_fillMovies_0.java:8)
       at movie.Rule_fillMovies_0ConsequenceInvoker.evaluate(Rule_fillMovies_0ConsequenceInvoker.java:28)
       at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:934)
       ... 7 more
TheEnd

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

        


From jira-events at lists.jboss.org  Tue Jul  7 11:29:52 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:29:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2194) CLONE
 -StatelessKnowledgeSessions created by KnowledgeAgent causes
 NullPointerException when used in a pipeline
Message-ID: <1933041400.1246980592620.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -StatelessKnowledgeSessions created by KnowledgeAgent causes NullPointerException when used in a pipeline
---------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2194
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2194
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
         Environment: 5.0.1.SNAPSHOT for May 12, 2009
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


This issue is related to this thread on the user-list:  http://www.mail-archive.com/rules-users at lists.jboss.org/msg08770.html

I'm getting a NullPointerException when I insert an object into
the pipeline using 5.0.1.SNAPSHOT from May 12, 2009:
java.lang.NullPointerException
        at 
org.drools.runtime.pipeline.impl.StatelessKnowledgeSessionPipelineImpl.insert(StatelessKnowledgeSessionPipelineImpl.java:24)

It looks like StatelessKnowledgeSession's ruleBase is null when created by the KnowledgeAgent, which poses a problem since StatelessKnowledgeSessionPipelineImpl invokes getRootClassLoader() on the session's ruleBase.

Here's what I'm doing:
StatelessKnowledgeSession ksession = kagent.newStatelessKnowledgeSession();
Pipeline pipeline =
PipelineFactory.newStatelessKnowledgeSessionPipeline(ksession);
pipeline.setReceiver(messageTransformer);
pipeline.insert(message);  // NPE here

I'll attach a patch to KnowledgeAgentTest containing a failing test case.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 11:31:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:31:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2195) CLONE -Memory
 leak on queries (regression)
Message-ID: <266952686.1246980711658.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Memory leak on queries (regression)
------------------------------------------

                 Key: JBRULES-2195
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2195
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.0.M5, 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


A leak was found when a rulebase contained 2 or more queries on it.


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

        


From jira-events at lists.jboss.org  Tue Jul  7 11:35:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:35:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2196) CLONE -Improve
 handling of value coercion into BigDecimal and BigInteger
Message-ID: <730394005.1246980951577.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Improve handling of value coercion into BigDecimal and BigInteger
------------------------------------------------------------------------

                 Key: JBRULES-2196
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2196
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler, drools-core
    Affects Versions: 5.0.0.M5, 5.0.0.CR1, 5.0.0.FINAL
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


Handle coercion into BigDecimal and BigInteger properly.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 11:41:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:41:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2198) CLONE
 -fireAllRules() blocks if called while fireUntilHalt() is running
Message-ID: <1273282122.1246981311589.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -fireAllRules() blocks if called while fireUntilHalt() is running
-----------------------------------------------------------------------

                 Key: JBRULES-2198
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2198
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.2, 5.1.0.M1


Drools work items call fireAllRules() automatically after completion. If the engine is already running fireUntilHalt() though, it blocks.


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

        


From jira-events at lists.jboss.org  Tue Jul  7 11:39:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:39:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2197) CLONE -Example
	source.
Message-ID: <2031554791.1246981191511.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Example source.
----------------------

                 Key: JBRULES-2197
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2197
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 5.0.1.FINAL
         Environment: Windows XP,eclipse
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


Hi! We are studying Drools 5.0 in order to use..
But a curious problem has happened, while executeing an example in documentation.

It is 3.1.3. Defining Processes Using the Process API in drools-5.0-docs\drools-flow\html_single\index.html.
Actually, 3.1.3.1. Example 1 is working normally, but 3.1.3.2. Example 2 and 3.1.3.3. Example 3 occur error.
I 'll tell you what we grasp the reason for error, so far.

When it's working normal, <ActionNode> exists.
The other way, when it is not working normal, <ActionNode> doesn't exist.
For example, in case of 3.1.3.2. Example 2

RuleFlowProcessFactory factory =
    RuleFlowProcessFactory.createProcess("org.drools.HelloWorldJoinSplit");
factory
    // Header
    .name("HelloWorldJoinSplit")
    .version("1.0")
    .packageName("org.drools")
    // Nodes
    .startNode(1).name("Start").done()
    .splitNode(2).name("Split").type(Split.TYPE_AND).done()
    .actionNode(3).name("Action 1")
        .action("mvel", "System.out.println(\"Inside Action 1\")").done()                <       -here, NullPointerException occurs.
    .actionNode(4).name("Action 2")
        .action("mvel", "System.out.println(\"Inside Action 2\")").done()
    .joinNode(5).type(Join.TYPE_AND).done()
    .endNode(6).name("End").done()
    // Connections
    .connection(1, 2)
    .connection(2, 3)
    .connection(2, 4)
    .connection(3, 5)
    .connection(4, 5)
    .connection(5, 6);
RuleFlowProcess process = factory.validate().getProcess();


Please, let me know entire source I can execute this example well.

Thank you for your consideration.

I am waiting for you answer.


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

        


From jira-events at lists.jboss.org  Tue Jul  7 11:45:51 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Jul 2009 11:45:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1678) OME on the
 Journal when processing too many files
Message-ID: <2117713915.1246981551955.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

OME on the Journal when processing too many files
-------------------------------------------------

                 Key: JBMESSAGING-1678
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1678
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0.beta3, 2.0.0.beta2, 2.0.0 Beta1
            Reporter: Clebert Suconic
            Assignee: Clebert Suconic
             Fix For: 2.0.0


Set one producer.. sending one message / second (about 200 messages)

Set another producer/consumer (in another destination) sending as fast as it can. (about 500K messages).

At the end you will have 200 files... but only 200 messages (one valid on each file).

This will lead to an OME.



On trunk, you need to deactivate compacting to replicate this.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 11:45:52 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Jul 2009 11:45:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1678) OME on the
 Journal when processing too many files
In-Reply-To: <2117713915.1246981551955.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1362307618.1246981552101.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1678:
-----------------------------------------

    Description: 
Set one producer.. sending one message / second (about 200 messages)

Set another producer/consumer (in another destination) sending as fast as it can. (about 500K messages).

At the end you will have 200 files... but only 200 messages (one valid on each file).

This will lead to an OME during reload.



On trunk, you need to deactivate compacting to replicate this.

  was:
Set one producer.. sending one message / second (about 200 messages)

Set another producer/consumer (in another destination) sending as fast as it can. (about 500K messages).

At the end you will have 200 files... but only 200 messages (one valid on each file).

This will lead to an OME.



On trunk, you need to deactivate compacting to replicate this.



> OME on the Journal when processing too many files
> -------------------------------------------------
>
>                 Key: JBMESSAGING-1678
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1678
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2, 2.0.0.beta3
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Set one producer.. sending one message / second (about 200 messages)
> Set another producer/consumer (in another destination) sending as fast as it can. (about 500K messages).
> At the end you will have 200 files... but only 200 messages (one valid on each file).
> This will lead to an OME during reload.
> On trunk, you need to deactivate compacting to replicate this.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 11:56:51 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 7 Jul 2009 11:56:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7052) when invoked from
 remote
 client, call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <997687701.1246982211650.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475234#action_12475234 ] 

Scott M Stark commented on JBAS-7052:
-------------------------------------

I'm breaking out the classes we return to clients into a jboss-profileservice-client.jar for inclusion on the client classpath. We return these delegate objects when we create proxies for runtime operations and properties that need to be dispatched to a server side component.


> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

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

        


From jira-events at lists.jboss.org  Tue Jul  7 12:14:51 2009
From: jira-events at lists.jboss.org (Adrian Woodhead (JIRA))
Date: Tue, 7 Jul 2009 12:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1679)
 http://wiki.jboss.org/wiki/Wiki.jsp?page=HelpBugReport
Message-ID: <318505980.1246983291590.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

http://wiki.jboss.org/wiki/Wiki.jsp?page=HelpBugReport
------------------------------------------------------

                 Key: JBMESSAGING-1679
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1679
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0.beta3
            Reporter: Adrian Woodhead
            Assignee: Tim Fox


Refer to http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242246#4242246 for more information, stack trace etc.

In essence the problem seems to be messages with an expiry time set seem to have problems when pre-ack mode is used.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 12:14:51 2009
From: jira-events at lists.jboss.org (Adrian Woodhead (JIRA))
Date: Tue, 7 Jul 2009 12:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1679) Could not
 find reference with id
In-Reply-To: <318505980.1246983291590.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <595842045.1246983291866.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adrian Woodhead updated JBMESSAGING-1679:
-----------------------------------------

    Summary: Could not find reference with id  (was: http://wiki.jboss.org/wiki/Wiki.jsp?page=HelpBugReport)


> Could not find reference with id
> --------------------------------
>
>                 Key: JBMESSAGING-1679
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1679
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>            Reporter: Adrian Woodhead
>            Assignee: Tim Fox
>
> Refer to http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242246#4242246 for more information, stack trace etc.
> In essence the problem seems to be messages with an expiry time set seem to have problems when pre-ack mode is used.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 13:37:51 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 7 Jul 2009 13:37:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7083) Add bean to install
 executor in AbstractController to as bootstrap
Message-ID: <1299419994.1246988271497.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add bean to install executor in AbstractController to as bootstrap
------------------------------------------------------------------

                 Key: JBAS-7083
                 URL: https://jira.jboss.org/jira/browse/JBAS-7083
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For: JBossAS-6.0.0.Alpha1




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

        


From jira-events at lists.jboss.org  Tue Jul  7 13:37:51 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 7 Jul 2009 13:37:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7083) Add bean to install
 executor in AbstractController to as bootstrap
In-Reply-To: <1299419994.1246988271497.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1295859546.1246988271558.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed JBAS-7083.
----------------------------

    Resolution: Done


> Add bean to install executor in AbstractController to as bootstrap
> ------------------------------------------------------------------
>
>                 Key: JBAS-7083
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7083
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: JBossAS-6.0.0.Alpha1
>
>


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

        


From jira-events at lists.jboss.org  Tue Jul  7 13:48:51 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 7 Jul 2009 13:48:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7083) Add bean to
 install executor in AbstractController to as bootstrap
In-Reply-To: <1299419994.1246988271497.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <643703691.1246988931520.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475263#action_12475263 ] 

Kabir Khan commented on JBAS-7083:
----------------------------------

To actually see the asynch behaviour, an MC version containing JBKERNEL-25 is needed

> Add bean to install executor in AbstractController to as bootstrap
> ------------------------------------------------------------------
>
>                 Key: JBAS-7083
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7083
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: JBossAS-6.0.0.Alpha1
>
>


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

        


From jira-events at lists.jboss.org  Tue Jul  7 13:59:51 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Jul 2009 13:59:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1935333346.1246989591757.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic reassigned JBMESSAGING-1677:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)


> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Clebert Suconic
>         Attachments: JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

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

        


From jira-events at lists.jboss.org  Tue Jul  7 13:59:51 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Jul 2009 13:59:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1407983860.1246989591888.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1677.
----------------------------------------

    Resolution: Cannot Reproduce Bug


> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Clebert Suconic
>         Attachments: JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

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

        


From jira-events at lists.jboss.org  Tue Jul  7 14:48:51 2009
From: jira-events at lists.jboss.org (Art Plata (JIRA))
Date: Tue, 7 Jul 2009 14:48:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1661) Messages in
 JBoss 5.1
 that use bridging get stuck in a devlivering mode and are not sent to the
 remote cluster
In-Reply-To: <29236051.1245359337536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1620742860.1246992531548.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475272#action_12475272 ] 

Art Plata commented on JBMESSAGING-1661:
----------------------------------------

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

> Messages in JBoss 5.1 that use bridging get stuck in a devlivering mode and are not sent to the remote cluster
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1661
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1661
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.3.GA
>         Environment: Linux -- JBoss 5.1 GA / JBM 1.4.3GA / Remoting 2.5.1
>            Reporter: Peter Crossley
>            Assignee: Howard Gao
>             Fix For: 1.4.5.GA
>
>
> A Message bridge between to clusters will get in to a state where the messages will not be picked up by the bridge on the topic/queue and remain in the "delivering" counter until the bridge is restarted via the JMX console or by restarting the Jboss instance.
> I attempted to use JBM 1.4.4 which has a fix (JBMESSAGING-1456) that seems to be the same issue, though do to the difference in the remoting I cannot use the 1.4.4 GA release.
> Can we get the fixes that were applied to the 1.4.4 release in a usable build for JBoss AS 5.1

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

        


From jira-events at lists.jboss.org  Tue Jul  7 15:14:51 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 7 Jul 2009 15:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <15950453.1246994091517.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475277#action_12475277 ] 

Stan Silvert commented on JBAS-7032:
------------------------------------

Shelly, I reproduced the NPE you were talking about:

12:36:01,025 ERROR [Digester] End event threw exception
java.lang.reflect.InvocationTargetException
        at sun.reflect.GeneratedMethodAccessor289.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:216)
        at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:217)
        at org.apache.commons.digester.Rule.end(Rule.java:253)
        at org.apache.commons.digester.Digester.endElement(Digester.java:1222)

Caused by: java.lang.NullPointerException
        at org.ajax4jsf.resource.InternetResourceBase.restoreData(InternetResourceBase.java:248)
        at org.richfaces.renderkit.html.Paint2DResource.getRenderer(Paint2DResource.java:68)
        at org.ajax4jsf.resource.ResourceBuilderImpl.addResource(ResourceBuilderImpl.java:406)

This is easily reproduced by just cold-deploying the EAR attached to this JIRA.  However, this EAR has several web jars that are in WhatUpDawg.ear/lib that probably shouldn't be there.  I moved these to WhatUpDawg.ear/WhatUpDawg.war/WEB-INF/lib:
jsf-facelets.jar
jsf-tlds.jar (You shouldn't need this because the server exposes a global copy)
jstl.jar (You shouldn't need this because the server exposes a global copy)
richfaces-api-3.3.1.GA.jar
richfaces-impl-3.3.1.GA.jar
richfaces-ui-3.3.1.GA.jar

So with these "web" jars in the proper place, Shelly's problem goes away.  Was there some reason that you wanted to move Facelets and RichFaces outside of the war?

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 17:01:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 7 Jul 2009 17:01:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-95) Create server states
 to account for callbacks before and after server init
Message-ID: <1641073694.1247000511604.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Create server states to account for callbacks before and after server init
--------------------------------------------------------------------------

                 Key: JBBOOT-95
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-95
             Project: JBoss Bootstrap
          Issue Type: Task
          Components: impl-base, spi
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger


We need to be able to have lifecycle callbacks take place either right before or right after server initialization.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 17:03:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 7 Jul 2009 17:03:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-95) Create server states
 to account for callbacks before and after server init
In-Reply-To: <1641073694.1247000511604.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1600191925.1247000631682.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated JBBOOT-95:
--------------------------------------

    Fix Version/s: impl-base-2.0.0-alpha-2
                   spi-2.0.0-alpha-2 


> Create server states to account for callbacks before and after server init
> --------------------------------------------------------------------------
>
>                 Key: JBBOOT-95
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-95
>             Project: JBoss Bootstrap
>          Issue Type: Task
>          Components: impl-base, spi
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: impl-base-2.0.0-alpha-2, spi-2.0.0-alpha-2 
>
>
> We need to be able to have lifecycle callbacks take place either right before or right after server initialization.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 17:23:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 7 Jul 2009 17:23:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-95) Create server
 states to account for callbacks before and after server init
In-Reply-To: <1641073694.1247000511604.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <357280608.1247001831562.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-95.
---------------------------------------

    Resolution: Done


> Create server states to account for callbacks before and after server init
> --------------------------------------------------------------------------
>
>                 Key: JBBOOT-95
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-95
>             Project: JBoss Bootstrap
>          Issue Type: Task
>          Components: impl-base, spi
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: impl-base-2.0.0-alpha-2, spi-2.0.0-alpha-2 
>
>
> We need to be able to have lifecycle callbacks take place either right before or right after server initialization.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 17:37:51 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Jul 2009 17:37:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1678) OME on the
 Journal when processing too many files
In-Reply-To: <2117713915.1246981551955.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1512107454.1247002671522.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475298#action_12475298 ] 

Clebert Suconic commented on JBMESSAGING-1678:
----------------------------------------------

This is because the method load has two lists:

      final Set<Long> recordsToDelete = new HashSet<Long>();
      final List<RecordInfo> records = new ArrayList<RecordInfo>();


The method load will add to both recordsToDelete and records.  At the end of the method, it will only consider the records that were not deleted:

      for (RecordInfo record : records)
      {
         if (!recordsToDelete.contains(record.id))
         {
            committedRecords.add(record);
         }
      }



But In a scenario where compacting is not working, records and recordsToDelete will grow too large, up to the point it won't fit on the memory in a single load.


We could just make compacting mandatory, or change the loading method to use some sort of Map. It's a bit of a challange here as the journal needs to keep the adds and update records in order.

> OME on the Journal when processing too many files
> -------------------------------------------------
>
>                 Key: JBMESSAGING-1678
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1678
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2, 2.0.0.beta3
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Set one producer.. sending one message / second (about 200 messages)
> Set another producer/consumer (in another destination) sending as fast as it can. (about 500K messages).
> At the end you will have 200 files... but only 200 messages (one valid on each file).
> This will lead to an OME during reload.
> On trunk, you need to deactivate compacting to replicate this.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 17:39:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 7 Jul 2009 17:39:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-96) Extract
	initialization logic
Message-ID: <1674931690.1247002791408.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Extract initialization logic
----------------------------

                 Key: JBBOOT-96
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-96
             Project: JBoss Bootstrap
          Issue Type: Task
          Components: impl-as, impl-base, impl-mc
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 2.0.0-beta-1 


With JBBOOT-95 we now have pre/post states for server initialization.  This means that the initialize() method must be marked final such that its logic containing when to fire the state changes cannot be overridden.  We still need to provide a mechanism for subclasses of AbstractServer to carry out their own initialization logic, so extract this into a "doInitialize()", much like we have a "doStart()".

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

        


From jira-events at lists.jboss.org  Tue Jul  7 17:52:52 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 7 Jul 2009 17:52:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-98) Update the full
 dependency chain to 2.0.0-beta-X level
Message-ID: <1900220212.1247003572283.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Update the full dependency chain to 2.0.0-beta-X level
------------------------------------------------------

                 Key: JBBOOT-98
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-98
             Project: JBoss Bootstrap
          Issue Type: Task
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 2.0.0-beta-1 


All subprojects must go to 2.0.0-beta-X before the beta releases are done (in order)

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

        


From jira-events at lists.jboss.org  Tue Jul  7 17:52:52 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 7 Jul 2009 17:52:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-97) Initialize VFS
 during server initialization
Message-ID: <447861720.1247003572218.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Initialize VFS during server initialization
-------------------------------------------

                 Key: JBBOOT-97
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-97
             Project: JBoss Bootstrap
          Issue Type: Task
          Components: impl-as
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 2.0.0-beta-1 


Use the new LifecycleStates defined by JBBOOT-95 to init VFS during server initialization

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

        


From jira-events at lists.jboss.org  Tue Jul  7 18:00:52 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 7 Jul 2009 18:00:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1678) OME on the
 Journal when processing too many files
In-Reply-To: <2117713915.1246981551955.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1379357988.1247004052007.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475302#action_12475302 ] 

Tim Fox commented on JBMESSAGING-1678:
--------------------------------------

If you want an ordered map there's always LinkedHashMap.

> OME on the Journal when processing too many files
> -------------------------------------------------
>
>                 Key: JBMESSAGING-1678
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1678
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2, 2.0.0.beta3
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Set one producer.. sending one message / second (about 200 messages)
> Set another producer/consumer (in another destination) sending as fast as it can. (about 500K messages).
> At the end you will have 200 files... but only 200 messages (one valid on each file).
> This will lead to an OME during reload.
> On trunk, you need to deactivate compacting to replicate this.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 18:10:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 7 Jul 2009 18:10:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-97) Initialize VFS
 during server initialization
In-Reply-To: <447861720.1247003572218.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <509733698.1247004651625.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-97.
---------------------------------------

    Resolution: Done


Resolving, but we won't see the effect here until JBBOOT-96 is done.

> Initialize VFS during server initialization
> -------------------------------------------
>
>                 Key: JBBOOT-97
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-97
>             Project: JBoss Bootstrap
>          Issue Type: Task
>          Components: impl-as
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 2.0.0-beta-1 
>
>
> Use the new LifecycleStates defined by JBBOOT-95 to init VFS during server initialization

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

        


From jira-events at lists.jboss.org  Tue Jul  7 18:12:51 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Jul 2009 18:12:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1678) OME on the
 Journal when processing too many files
In-Reply-To: <2117713915.1246981551955.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <19811250.1247004771512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475306#action_12475306 ] 

Clebert Suconic commented on JBMESSAGING-1678:
----------------------------------------------

That's not what I meant.

As far as I'm in concern, the updates needs to be in order...


if you did

Add,1
Add2,
Update1
Update2


I need to load them at the same order. as the Update could be a transfer to a DLQ, redelivery.. etc. 


If I used some ordered map, the result at the end would be:

Add1, 
Update1
Add2, 
Update2




Unless you tell me this would be ok.

> OME on the Journal when processing too many files
> -------------------------------------------------
>
>                 Key: JBMESSAGING-1678
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1678
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2, 2.0.0.beta3
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Set one producer.. sending one message / second (about 200 messages)
> Set another producer/consumer (in another destination) sending as fast as it can. (about 500K messages).
> At the end you will have 200 files... but only 200 messages (one valid on each file).
> This will lead to an OME during reload.
> On trunk, you need to deactivate compacting to replicate this.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 18:37:52 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Jul 2009 18:37:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1678) OME on the
 Journal when processing too many files
In-Reply-To: <2117713915.1246981551955.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1725265961.1247006272118.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1678:
-----------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=158140


> OME on the Journal when processing too many files
> -------------------------------------------------
>
>                 Key: JBMESSAGING-1678
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1678
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2, 2.0.0.beta3
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Set one producer.. sending one message / second (about 200 messages)
> Set another producer/consumer (in another destination) sending as fast as it can. (about 500K messages).
> At the end you will have 200 files... but only 200 messages (one valid on each file).
> This will lead to an OME during reload.
> On trunk, you need to deactivate compacting to replicate this.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 19:04:03 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 7 Jul 2009 19:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7052) when invoked from
 remote client, 
 call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1557473021.1247007843593.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-7052.
---------------------------------

    Resolution: Done


I have created a jboss-profileservice-client.jar artifact that I can use to get past any profileservice related errors. This requires the addition of the following org.jboss.jbossas:jboss-as-profileservice:client dependency:

[524][valkyrie: jbas5-plugin-descriptor-gen]$ svn diff pom.xml 
Index: pom.xml
===================================================================
--- pom.xml	(revision 879)
+++ pom.xml	(working copy)
@@ -193,6 +193,13 @@
             <classifier>client</classifier>
             <scope>runtime</scope>
         </dependency>
+        <dependency>
+            <groupId>org.jboss.jbossas</groupId>
+            <artifactId>jboss-as-profileservice</artifactId>
+            <classifier>client</classifier>
+            <scope>runtime</scope>
+            <version>5.1.0-SNAPSHOT</version>
+        </dependency>
 
         <dependency>
           <groupId>org.jboss</groupId>
[525][valkyrie: jbas5-plugin-descriptor-gen]$



> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

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

        


From jira-events at lists.jboss.org  Tue Jul  7 19:33:51 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Jul 2009 19:33:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1678) OME on the
 Journal when processing too many files
In-Reply-To: <2117713915.1246981551955.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <456793071.1247009631437.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1678.
----------------------------------------

    Resolution: Done


I have committed a fix, and added a stress test to validate this issue.

I didn't want to change any ordering on the journal, so I added a cleanup on every X records as discussed on the forums. 

We will revisit this issue if this is not acceptable.

> OME on the Journal when processing too many files
> -------------------------------------------------
>
>                 Key: JBMESSAGING-1678
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1678
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2, 2.0.0.beta3
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Set one producer.. sending one message / second (about 200 messages)
> Set another producer/consumer (in another destination) sending as fast as it can. (about 500K messages).
> At the end you will have 200 files... but only 200 messages (one valid on each file).
> This will lead to an OME during reload.
> On trunk, you need to deactivate compacting to replicate this.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 19:46:51 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 7 Jul 2009 19:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-1140) Bisocket client
 cannot detect connection failure
Message-ID: <2071003850.1247010411469.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Bisocket client cannot detect connection failure
------------------------------------------------

                 Key: JBREM-1140
                 URL: https://jira.jboss.org/jira/browse/JBREM-1140
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: transport
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 2.2.3.SP1


The BisocketClientInvoker never reads from the control socket.  Therefore, it might take a long time for it to notice that the control connection dies, causing confusion between the client and server (for example, the client may reuse a listener ID that the server considers extinct).  By adding a ping reply mechanism, the client must both send and receive a ping for the connection to be known "good", which should help speed up the dead connection detection process.

Since this change is protocol-incompatible, it should be enabled by a configuration option.  I'm using Bisocket.ENABLE_PING_REPLY = "enablePingReply" for this purpose.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 20:12:51 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 7 Jul 2009 20:12:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-1140) Bisocket client
 cannot detect connection failure
In-Reply-To: <2071003850.1247010411469.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <12853602.1247011971511.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBREM-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475331#action_12475331 ] 

David Lloyd commented on JBREM-1140:
------------------------------------

The correct name of the option is "enablePingReplies", plural.

> Bisocket client cannot detect connection failure
> ------------------------------------------------
>
>                 Key: JBREM-1140
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1140
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: transport
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 2.2.3.SP1
>
>
> The BisocketClientInvoker never reads from the control socket.  Therefore, it might take a long time for it to notice that the control connection dies, causing confusion between the client and server (for example, the client may reuse a listener ID that the server considers extinct).  By adding a ping reply mechanism, the client must both send and receive a ping for the connection to be known "good", which should help speed up the dead connection detection process.
> Since this change is protocol-incompatible, it should be enabled by a configuration option.  I'm using Bisocket.ENABLE_PING_REPLY = "enablePingReply" for this purpose.

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

        


From jira-events at lists.jboss.org  Tue Jul  7 21:45:51 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 7 Jul 2009 21:45:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
In-Reply-To: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <467680049.1247017551672.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-7051.
---------------------------------

    Resolution: Done


There can only be one underlying msg provider in jbossas5, so there would not be two different destination managed objects. We have org.jboss.mq.server.jmx.* wrapper classes that are exposing the legacy destinations classes and managed objects. I have updated the MODefintion mappings in the messaging-definitions-jboss-beans.xml deployment to map these legacy classes onto the same MO as the current jms destinations.


> ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7051
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ejb3-tutorial-mdb.jar
>
>
> This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:
> 1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.
> 2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:
> container=JBossMQ|JBossMessaging
> which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.
> Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:
> 15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
> ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
> rvice=Queue, parent=JBoss EAP 5 (default)]
> org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
>         at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
>         at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
> rceManager.java:235)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
> figurationUIBean.java:144)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.seam.util.Reflections.invoke(Reflections.java:22)
>         at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
>         at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
> tion(ResourceConfigurationUIBean_$$_javassist_12.java)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
>         at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
>         at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
>         at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
>         at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
>         at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
>         at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
>         at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
>         at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
>         at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
>         at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>         at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>         at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
>         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:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
> a:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
> :70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
> operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
> a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
> ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
> ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
>         ... 84 more

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

        


From jira-events at lists.jboss.org  Tue Jul  7 23:17:51 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 7 Jul 2009 23:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1644) Work out a
 suitable way to provide JBM examples/doc for AS 5
In-Reply-To: <25933843.1244563136418.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <644754300.1247023071478.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1644.
-----------------------------------

    Resolution: Done


done

> Work out a suitable way to provide JBM examples/doc for AS 5
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1644
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1644
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: AS Integration
>    Affects Versions: 1.4.3.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>            Priority: Critical
>             Fix For: 1.4.5.GA
>
>
> Current AS 5 distribution kit doesn't have JBM doc/examples of the corresponding version included, that makes it very inconvenient to use JBM with AS5. Users often get confused with which version of JBM is the correct version, and where to get the resouces (docs, examples).
> We have to provide a solution to that. 

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

        


From jira-events at lists.jboss.org  Wed Jul  8 01:51:08 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 8 Jul 2009 01:51:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1680) Improving the
 startup of Messaging Post Office service
Message-ID: <443833333.1247032268842.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Improving the startup of Messaging Post Office service
------------------------------------------------------

                 Key: JBMESSAGING-1680
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1680
             Project: JBoss Messaging
          Issue Type: Feature Request
          Components: JMS Clustering
    Affects Versions: 1.4.4.GA, 1.4.0.SP3.CP08
            Reporter: Howard Gao
            Assignee: Howard Gao
             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA


Investigating the possibility of starting the two JGroups channels concurrently so that the startup process will be faster.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 04:19:51 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Wed, 8 Jul 2009 04:19:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7029) Test
 org.jboss.test.profileservice.test.PlatformMBeanUnitTestCase(profileservice).testThreadMXBean
 fails on JDK6
In-Reply-To: <9161934.1245234836800.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <849784752.1247041191722.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved JBAS-7029.
---------------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
       Resolution: Done


> Test org.jboss.test.profileservice.test.PlatformMBeanUnitTestCase(profileservice).testThreadMXBean fails on JDK6
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7029
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7029
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows and Linux 
> JDK6
>            Reporter: Pavel Slavicek
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Test org.jboss.test.profileservice.test.PlatformMBeanUnitTestCase(profileservice).testThreadMXBean fails on JDK6 on line 
>       Set<ManagedOperation> ops = mo.getOperations();
>       log.debug(ops);
>       assertEquals("Ops count is 8", 8, ops.size());
> JDK6 contains JMX 1.4 and ThreadMXBean has 11 operations.
> Test log:
> junit.framework.AssertionFailedError: Ops count is 8 expected:&lt;8&gt; but was:&lt;11&gt;

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

        


From jira-events at lists.jboss.org  Wed Jul  8 04:47:03 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 8 Jul 2009 04:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1617) JBM does not
 handle
 java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes()
 when copying a foreign message.
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <419731774.1247042823446.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1617.
-----------------------------------



introduced a system property 'support.bytesId'. If set to false, JBossMessage will not use the bytes ID of the foreign message. Otherwise it stays as before. Document 2.3.1 has added for this.

> JBM does not handle java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes() when copying a foreign message.
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Some providers can throw UnsupportedOperationException from getCorrelationIDBytes(). This is called in the foreign message constructor of a JBM message. Currently JBM will fail to copy the message since the exception is not handled.
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

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

       



From jira-events at lists.jboss.org  Wed Jul  8 05:14:51 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 8 Jul 2009 05:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1667) MBeans
 cannot have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1472323869.1247044491449.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475374#action_12475374 ] 

Howard Gao commented on JBMESSAGING-1667:
-----------------------------------------

We can check the name in DestinationServiceSupport.startService(), if it contains forward slash, throw an exception, that make the deployment fail.

         if (name.contains("/"))
         {
            throw new IllegalStateException("The " + (isQueue() ? "queue" : "topic") +
                                            " " +
                                            "name should not contain forward slash " + name);
         }


> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 07:45:51 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Wed, 8 Jul 2009 07:45:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1679) Could not
 find reference with id
In-Reply-To: <318505980.1246983291590.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1055797765.1247053551532.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor reassigned JBMESSAGING-1679:
----------------------------------------

    Assignee: Andy Taylor  (was: Tim Fox)


> Could not find reference with id
> --------------------------------
>
>                 Key: JBMESSAGING-1679
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1679
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>            Reporter: Adrian Woodhead
>            Assignee: Andy Taylor
>
> Refer to http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242246#4242246 for more information, stack trace etc.
> In essence the problem seems to be messages with an expiry time set seem to have problems when pre-ack mode is used.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 08:32:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 8 Jul 2009 08:32:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <97337339.1247056371576.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBXB-206:
---------------------------------

    Attachment: jbossxb-2.zip


> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>            Assignee: Alexey Loubyansky
>         Attachments: jboss-profiler.properties, jbossxb-2.zip, jbossxb.zip, server-2.log.gz, server.log.gz
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 09:44:05 2009
From: jira-events at lists.jboss.org (Alan Gairey (JIRA))
Date: Wed, 8 Jul 2009 09:44:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2199)
 NullPointerException with JPA session persistence in Drools Flow
Message-ID: <233050457.1247060645508.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

NullPointerException with JPA session persistence in Drools Flow
----------------------------------------------------------------

                 Key: JBRULES-2199
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2199
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core (flow)
    Affects Versions: 5.0.1.FINAL
            Reporter: Alan Gairey
            Assignee: Mark Proctor


I'm currently using Drools Flow with JPA session persistence enabled as described in section 5.1 of the User Guide.
As a process executes, session information is saved to the H2 database correctly.

The problem comes when recreating a session from its persisted state, using the code:

{code}
// recreate the session from database using the sessionId
ksession = JPAKnowledgeService.loadStatefulKnowledgeSession( sessionId, kbase, null, env );
{code}

This gives me a NullPointerException.

Having looked into the Drools Flow source code, I think the problem is in the class drools-persistence-jpa\src\main\java\org\drools\persistence\session\SingleSessionCommandService.java.

The 4th constructor of this class (starting line 132) is called as part of the loading of a knowledge session from the H2 database (i.e. via the code above); this in turn leads to the afterCompletion method of the inner class SynchronizationImpl being called. The final two lines of this method are:

{code}
((JPAProcessInstanceManager) ((ReteooWorkingMemory) session).getProcessInstanceManager()).clearProcessInstances();
((JPAWorkItemManager) ((ReteooWorkingMemory) session).getWorkItemManager()).clearWorkItems();
{code}

However, when called via the route described above, the session member variable of SingleSessionCommandService has not been set, thus causing the NullPointerException.

(Interestingly, running the unit tests for drools-persistence-jpa does result in a NullPointerException being thrown multiple times, although the tests are still listed as having passed.)

I believe enclosing the above two lines as follows will fix the problem:

{code}
if (session != null) { 
    ((JPAProcessInstanceManager) ((ReteooWorkingMemory) session).getProcessInstanceManager()).clearProcessInstances(); 
    ((JPAWorkItemManager) ((ReteooWorkingMemory) session).getWorkItemManager()).clearWorkItems(); 
} 
{code}

Also, in the 4th constructor of SingleSessionCommandService, after the session has been set, the following line needs to be added to ensure the session id is the same as the session info id:

{code}
((ReteooStatefulSession) this.session).setId( this.sessionInfo.getId() );
{code}

(This line _is_ present at the end of the 3rd constructor - line 123.)

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

        


From jira-events at lists.jboss.org  Wed Jul  8 10:28:51 2009
From: jira-events at lists.jboss.org (Andre Malenfant (JIRA))
Date: Wed, 8 Jul 2009 10:28:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2200) Add the ablility
 to add an excel decision table and drl template in a changeset
Message-ID: <9653463.1247063331424.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add the ablility to add an excel decision table and drl template in a changeset
-------------------------------------------------------------------------------

                 Key: JBRULES-2200
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2200
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-compiler, drools-decisiontables
            Reporter: Andre Malenfant
            Assignee: Mark Proctor


Currently, change sets can contain Excel decision tables that will be automatically compiled. This allows to use the Agent functionality to have the decision table automatically recompiled upon a change to the Excel file. This only works for decision tables that contain the necessary metadata to generate the rules but does not work for "plain" decision tables that are compiled programatically by providing a template drl and using an ExternalSpreadsheetCompiler.

It would be very useful to be able to specify a decision table and the corresponding drl template in a change set and be able to use the Agent functionality to have the rules recompiled automatically when one or the other file changes.


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

        


From jira-events at lists.jboss.org  Wed Jul  8 10:43:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 8 Jul 2009 10:43:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7084) Add support for a
 traditional XA strategy in the JMS resource adapter
Message-ID: <953042023.1247064231431.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add support for a traditional XA strategy in the JMS resource adapter
---------------------------------------------------------------------

                 Key: JBAS-7084
                 URL: https://jira.jboss.org/jira/browse/JBAS-7084
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JCA service
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


Add support for a traditional (JCA 1.5 Chapter 12.5.6 Option A) XA transaction model in the generic JMS resource adapter.

The default when using an XASession should be the traditional one, but the old behavior can be enabled by setting the ForceTransacted flag in the activation spec.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 10:45:51 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 8 Jul 2009 10:45:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <1353402761.1247064351886.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475449#action_12475449 ] 

Stan Silvert commented on JBAS-7032:
------------------------------------

I think I see what the problem is. So after you get rid of the NPE by moving the jars, you try to hit the admin console and see the stack trace reported earlier.

I notice that this stack trace contains WebBeansPhaseListener. This is installed automatically by JSF when it sees the /webbeans.deployer/lib-int/faces in the classpath. /webbeans.deployer/lib-int/faces/META-INF/faces-config.xml has an entry that tells JSF to load the WebBeansPhaseListener.

Since admin console doesn't use WebBeans, this should not happen. So I suspect that the problem is with the WebBeans deployer. I'm guessing that it is placing the /webbeans.deployer/lib-int/faces in some classpath that is visible by the admin console's ServletContext resource path.

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 11:16:51 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 8 Jul 2009 11:16:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-212)
 SchemaBindingValidator should pass
 default schema resolver in case SchemaBinding doesn't have one
Message-ID: <1096870749.1247066211458.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SchemaBindingValidator should pass default schema resolver in case SchemaBinding doesn't have one
-------------------------------------------------------------------------------------------------

                 Key: JBXB-212
                 URL: https://jira.jboss.org/jira/browse/JBXB-212
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.2.Beta1
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: JBossXB-2.0.2.GA


The following method

public void validate(InputSource is, SchemaBinding binding)

will use binding.getSchemaResolver() to load schemas referenced from the main XSD. If the binding is not associated with a SchemaBindingResolver then the default resolver should be used.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 11:36:51 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 8 Jul 2009 11:36:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-212) SchemaBindingValidator
 should pass
 default schema resolver in case SchemaBinding doesn't have one
In-Reply-To: <1096870749.1247066211458.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1338850780.1247067411450.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBXB-212.
----------------------------------

    Resolution: Done


Fixed. SchemaBindingValidator now has a property schemaResolver which can be initialized with constructor or the setter.

> SchemaBindingValidator should pass default schema resolver in case SchemaBinding doesn't have one
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBXB-212
>                 URL: https://jira.jboss.org/jira/browse/JBXB-212
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.2.Beta1
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossXB-2.0.2.GA
>
>
> The following method
> public void validate(InputSource is, SchemaBinding binding)
> will use binding.getSchemaResolver() to load schemas referenced from the main XSD. If the binding is not associated with a SchemaBindingResolver then the default resolver should be used.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 11:38:51 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 8 Jul 2009 11:38:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBXB-212)
 SchemaBindingValidator should
 pass default schema resolver in case SchemaBinding doesn't have one
In-Reply-To: <1096870749.1247066211458.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <723508262.1247067531513.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBXB-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475459#action_12475459 ] 

Alexey Loubyansky commented on JBXB-212:
----------------------------------------

Also, AbstractMutableSchemaResolver when creating an instance of SchemaBindingValidator will initialize its schemaResolver to itself.

> SchemaBindingValidator should pass default schema resolver in case SchemaBinding doesn't have one
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBXB-212
>                 URL: https://jira.jboss.org/jira/browse/JBXB-212
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.2.Beta1
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossXB-2.0.2.GA
>
>
> The following method
> public void validate(InputSource is, SchemaBinding binding)
> will use binding.getSchemaResolver() to load schemas referenced from the main XSD. If the binding is not associated with a SchemaBindingResolver then the default resolver should be used.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 11:52:52 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 8 Jul 2009 11:52:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-7052) when invoked from
 remote client, 
 call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1322152111.1247068372218.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer reopened JBAS-7052:
--------------------------------



> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

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

        


From jira-events at lists.jboss.org  Wed Jul  8 11:52:51 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 8 Jul 2009 11:52:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7052) when invoked from
 remote
 client, call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <180217318.1247068371902.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475460#action_12475460 ] 

Ian Springer commented on JBAS-7052:
------------------------------------

I updated the pom.xml for https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/  to contain a dep on the new client jar, but it still fails with:

Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
        at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
        at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:247)
        at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
        at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
        at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at java.util.HashSet.readObject(HashSet.java:291)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at java.util.HashSet.readObject(HashSet.java:291)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
        at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
        at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
        at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

So it's still looking for org.jboss.profileservice.management.ManagedOperationDelegate, even though it looks like the class's package was changed to org.jboss.profileservice.management.client in the new client jar...


> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

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

        


From jira-events at lists.jboss.org  Wed Jul  8 11:54:51 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 8 Jul 2009 11:54:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7052) when invoked from
 remote
 client, call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1563441289.1247068491636.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475461#action_12475461 ] 

Ian Springer commented on JBAS-7052:
------------------------------------

Scott, it looks like you only made this fix in the Branch_5_x branch. I'm using the EAP5 branch. Can you make the change in that branch too?


> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

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

        


From jira-events at lists.jboss.org  Wed Jul  8 12:13:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 8 Jul 2009 12:13:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7084) Add support for a
 traditional XA strategy in the JMS resource adapter
In-Reply-To: <953042023.1247064231431.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1784671742.1247069631458.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBAS-7084.
-----------------------------------

    Resolution: Done


> Add support for a traditional XA strategy in the JMS resource adapter
> ---------------------------------------------------------------------
>
>                 Key: JBAS-7084
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7084
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Add support for a traditional (JCA 1.5 Chapter 12.5.6 Option A) XA transaction model in the generic JMS resource adapter.
> The default when using an XASession should be the traditional one, but the old behavior can be enabled by setting the ForceTransacted flag in the activation spec.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 12:58:51 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Wed, 8 Jul 2009 12:58:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6936) Testsuite fails
 during
 tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
In-Reply-To: <368622.1242662765255.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <595339338.1247072331703.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-6936:
---------------------------------

    Labels: profileservice  (was: )


> Testsuite fails during tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6936
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6936
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>
> The AS fails to start for the second time during the tests-profileservice target of the testsuite. This is caused by the first instance not being properly shutdown by the following ant command: <server:stop name="profileservice"/>

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

        


From jira-events at lists.jboss.org  Wed Jul  8 13:00:51 2009
From: jira-events at lists.jboss.org (Konstantin Pupkov (JIRA))
Date: Wed, 8 Jul 2009 13:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
Message-ID: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

fetch based on messageId doesn't work
-------------------------------------

                 Key: JBMESSAGING-1681
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.3.GA
         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
            Reporter: Konstantin Pupkov
            Assignee: Tim Fox


here is me code on client:
String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
Message msg1= recv.receive();---->hungs on forever


I tied
QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well


Please fix it and keep standard approach: JMSMessageID not JBMessageID.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 13:04:51 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 8 Jul 2009 13:04:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1361171846.1247072691678.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow reassigned JBAS-6185:
----------------------------------

    Assignee: Scott Marlow  (was: Shelly McGowan)


> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Scott Marlow
>            Priority: Blocker
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 13:09:51 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Jul 2009 13:09:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <426577827.1247072991527.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475470#action_12475470 ] 

Tim Fox commented on JBMESSAGING-1681:
--------------------------------------

Konstantin - if you're using the JMS API, then you should be using JMSMessageID, not JBMessageID, as per JMS spec.

Can you tell me where in the docs does it say to use JBMessageID?

Also can you please post a full test program that demonstrates the issue. Your code snippet does not go into enough detail.

> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Tim Fox
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 13:14:51 2009
From: jira-events at lists.jboss.org (asookazian (JIRA))
Date: Wed, 8 Jul 2009 13:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6549) Investigate
 increased memory requirements and deployment time
In-Reply-To: <5128231.1235670884495.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1105758036.1247073291772.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475471#action_12475471 ] 

asookazian commented on JBAS-6549:
----------------------------------

Why do these problems show up in GA versions and not before?  All JBoss has to do is load test a few apps and analyze results, no?

> Investigate increased memory requirements and deployment time
> -------------------------------------------------------------
>
>                 Key: JBAS-6549
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6549
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.0.GA, JBossAS-5.0.1.GA
>            Reporter: Dimitris Andreadis
>            Assignee: Ales Justin
>         Attachments: AS 5_x profiler snapshot.zip
>
>
> A user reported x2 increase in deployment time and x4 increase in memory usage when moving an application from JBoss 4.2 -> 5.x.
> We need to investigate how to improve both the memory usage and the deployment time.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 13:57:51 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 8 Jul 2009 13:57:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7052) when invoked from
 remote
 client, call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1038402196.1247075871655.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475482#action_12475482 ] 

Ian Springer commented on JBAS-7052:
------------------------------------

I got further after I updated my server to the latest bits, in addition to my client. However, now I get a CNFE for ManagedPropertyDelegate...

C:\Projects\jopr-trunk\modules\tools\jbas5-plugin-descriptor-gen\target>java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedPropertyDelegate
        at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
        at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:247)
        at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
        at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
        at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at java.util.HashMap.readObject(HashMap.java:1030)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at java.util.HashSet.readObject(HashSet.java:291)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
        at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
        at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
        at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)


> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

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

        


From jira-events at lists.jboss.org  Wed Jul  8 14:23:52 2009
From: jira-events at lists.jboss.org (Konstantin Pupkov (JIRA))
Date: Wed, 8 Jul 2009 14:23:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2020183138.1247077432338.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475492#action_12475492 ] 

Konstantin Pupkov commented on JBMESSAGING-1681:
------------------------------------------------

You didn't get my complain.
I tried JMSMessageID as well - it doesn't work. It works fine with JBOSS 4.1.GA.
I tried to find workaround that is why I tried "JBMessageID" in my sample.

here is link to JBMessageID:
JavaDoc class:
org.jboss.messaging.core.filter.impl.FilterImpl

public class FilterImpl
extends java.lang.Object
implements Filter

This class implements a JBoss Messaging filter

Version:
    $Revision: 3569 $ $Id: Selector.java 3569 2008-01-15 21:14:04Z timfox $
Author:
    Tim Fox, Jeff Mesnil JBM filters have the same syntax as JMS 1.1 selectors, but the identifiers are different. Valid identifiers that can be used are: *******!!!!!!!JBMessageID!!!!!!!!******** - the message id of the message JBMPriority - the priority of the message JBMTimestamp - the timestamp of the message JBMDurable - "DURABLE" or "NON_DURABLE" JBMExpiration - the expiration of the message JBMSize - the encoded size of the full message in bytes Any other identifers that appear in a filter expression represent header values for the message String values must be set as SimpleString, not java.lang.String (see JBMESSAGING-1307). Derived from JBoss MQ version by, Norbert Lataille, Juha Lindfors, Jason Dillon, Scott Stark, Tim Fox 




> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Tim Fox
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 14:35:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 8 Jul 2009 14:35:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-107) SJC: Add support
 for a default value in system properties
In-Reply-To: <803321689.1246904225294.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1833426754.1247078151761.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-107.
-----------------------------------

    Resolution: Done


> SJC: Add support for a default value in system properties
> ---------------------------------------------------------
>
>                 Key: JBJCA-107
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-107
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Core
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Add support for a default in system properties like
>  ${jboss.bind.address:localhost}

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

        


From jira-events at lists.jboss.org  Wed Jul  8 14:39:52 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Jul 2009 14:39:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <460152300.1247078392439.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475505#action_12475505 ] 

Tim Fox commented on JBMESSAGING-1681:
--------------------------------------

Konstantin-

That class FilterImpl is in the *JBM 2.0* code base. According to your report you are using JBM 1.4. JBM 1.4 and JBM 2.0 are pretty much completely different projects/codebases. Moreover that class is a *core filter* - it has nothing to do with JMS, however that's not relevant since you're not using JBM 2.0 anyway.

Regarding using JMSMessageID, we're still waiting for your test program that demonstrates the issue. It should just be a small program with a few lines of JMS code. Once you have provided that someone will investigate it.

> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Tim Fox
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 15:10:52 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 8 Jul 2009 15:10:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-106) SJC: Add support for
 property maps
In-Reply-To: <1148079522.1246903911428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <922163058.1247080252011.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-106:
----------------------------------

    Fix Version/s:     (was: 1.0.0.Alpha2)


> SJC: Add support for property maps
> ----------------------------------
>
>                 Key: JBJCA-106
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-106
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Core
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>
> Add support for property maps, so they can be passed in the configuration.
> The remotable naming server is an example of an use-case.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 15:33:51 2009
From: jira-events at lists.jboss.org (Mr X (JIRA))
Date: Wed, 8 Jul 2009 15:33:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6537) Ant task
 <jmx><setAttribute> problem : unable to use <value> tag inside
In-Reply-To: <2639620.1156486125456.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <59663339.1247081631557.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475515#action_12475515 ] 

Mr X commented on JBAS-6537:
----------------------------

Can anyone suggest a workaround or alternative library to accomplish setting an attribute while we wait for a fix?

> Ant task <jmx><setAttribute> problem : unable to use <value> tag inside
> -----------------------------------------------------------------------
>
>                 Key: JBAS-6537
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6537
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Windows XP, 
> JRE 1.5
> Eclipse 3.2
> Ant 1.6.5
>            Reporter: Benoit Lavenier
>
> The Ant task JMX (org.jboss.ant.JMX) has a code error in the subclass "Setter" (used by <setAttribute> sub task)
> The methode named setValue in Setter subclass should be "addValue"
> Please refer to the folowwing url : http://ant.apache.org/manual/develop.html  , and the "Supporting nested elements" section
> I think the following code will works fine :
>        // "setValue" method (of subclass Setter) remaned in "addValue"
>        public void addValue(Param value)
>        {
>     	   // This will only consider the last <value> tag, if more than one tag 
> 		   this.value = value;
>        }

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

        


From jira-events at lists.jboss.org  Wed Jul  8 16:05:51 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 8 Jul 2009 16:05:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7052) when invoked from
 remote
 client, call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <872657659.1247083551641.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475518#action_12475518 ] 

Scott M Stark commented on JBAS-7052:
-------------------------------------

I have moved the ManagedPropertyDelegate to the client jar and updated the org.jboss.jbossas:jboss-as-profileservice:client snapshot artifact. Both the server and the snapshot need to be updated to validate this.

> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

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

        


From jira-events at lists.jboss.org  Wed Jul  8 16:28:51 2009
From: jira-events at lists.jboss.org (Kit Chan (JIRA))
Date: Wed, 8 Jul 2009 16:28:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2201) Rule got executed
 even does not satisfy LHS after firing an external event in Flow
Message-ID: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Rule got executed even does not satisfy LHS after firing an external event in Flow
----------------------------------------------------------------------------------

                 Key: JBRULES-2201
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core  (expert)
    Affects Versions: 5.0.1.FINAL
         Environment: Windows XP SP3, Eclipse 3.4.2
            Reporter: Kit Chan
            Assignee: Mark Proctor


I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 16:36:51 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 8 Jul 2009 16:36:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7085) Replace ejb3 secured
 profile service facade with secured remoting proxy
Message-ID: <1810173299.1247085411421.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Replace ejb3 secured profile service facade with secured remoting proxy
-----------------------------------------------------------------------

                 Key: JBAS-7085
                 URL: https://jira.jboss.org/jira/browse/JBAS-7085
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ProfileService, Security
            Reporter: Scott M Stark
            Assignee: Scott M Stark
             Fix For: JBossAS-5.2.0.Beta1


Its been decided to limit the number of dependencies an admin client needs to communicate with a secured profile service. We need to drop the ejb3 facade and provide a secured remoting based proxy bound in global jndi and an unsecured, but security manager controlled unsecured proxy under the java: local jndi namespace.


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

        


From jira-events at lists.jboss.org  Wed Jul  8 16:38:51 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 8 Jul 2009 16:38:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7085) Replace ejb3 secured
 profile service facade with secured remoting proxy
In-Reply-To: <1810173299.1247085411421.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1774484964.1247085531489.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark updated JBAS-7085:
--------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242480


> Replace ejb3 secured profile service facade with secured remoting proxy
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7085
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7085
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService, Security
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Its been decided to limit the number of dependencies an admin client needs to communicate with a secured profile service. We need to drop the ejb3 facade and provide a secured remoting based proxy bound in global jndi and an unsecured, but security manager controlled unsecured proxy under the java: local jndi namespace.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 16:53:05 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 8 Jul 2009 16:53:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-108) SJC: Add support for
 <constructor>
In-Reply-To: <962038176.1246904932262.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1990097731.1247086385291.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-108.
-----------------------------------

    Resolution: Done


> SJC: Add support for <constructor>
> ----------------------------------
>
>                 Key: JBJCA-108
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-108
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Core
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Add support for <constructor> constructs for beans. 
> An example
>     <bean name="LookupPool">
>         <constructor factoryMethod="newFixedThreadPool"  factoryClass="java.util.concurrent.Executors">
>             <parameter>2</parameter>
>         </constructor>
>     </bean>

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

        


From jira-events at lists.jboss.org  Wed Jul  8 18:14:51 2009
From: jira-events at lists.jboss.org (Kevin Bates (JIRA))
Date: Wed, 8 Jul 2009 18:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
Message-ID: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Can't enlist in transaction with second Oracle XA connection/resource.
----------------------------------------------------------------------

                 Key: JBAS-7086
                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Transaction Manager (Arjuna)
    Affects Versions: JBossAS-5.0.1.GA
         Environment: The operating system has been windows, but that doesn't appear to be related.
Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
            Reporter: Kevin Bates
            Assignee: Jonathan Halliday


We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.

At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:

2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
oracle.jdbc.xa.OracleXAException
	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
<deleted due to 32K requirement>

2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
<deleted due to 32K requirement>


2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
	at java.lang.reflect.Method.invoke(Method.java:599)
	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
	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:404)
	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
	at org.jboss.ejb.Container.invoke(Container.java:1029)
	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
	at $Proxy134.executeChanges(Unknown Source)
	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
	at java.lang.reflect.Method.invoke(Method.java:599)
	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
	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:378)
	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
	at org.jboss.ejb.Container.invoke(Container.java:1029)
	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
	at $Proxy135.executeChanges(Unknown Source)
	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
	at java.security.AccessController.doPrivileged(AccessController.java:284)
	at javax.security.auth.Subject.doAs(Subject.java:573)
	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
	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:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:735)
Caused by: 
org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
	... 90 more
Caused by: 
org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
	... 92 more
Caused by: 
javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
	... 96 more


The two XA data sources are configured as follows:

<datasources>
 <xa-datasource>
      <jndi-name>OraDSXA</jndi-name>
      <use-java-context>false</use-java-context>
		<set-tx-query-timeout/>
      <track-connection-by-tx/>
      <isSameRM-override-value>false</isSameRM-override-value>
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
      <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
      <xa-datasource-property name="User">OS1</xa-datasource-property>
      <xa-datasource-property name="Password">xxxx</xa-datasource-property>
      <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
      <no-tx-separate-pools/>
      <metadata>
      <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
          <type-mapping>Oracle9i</type-mapping>
      </metadata>
  </xa-datasource>
</datasources>

<datasources>
 <xa-datasource>
      <jndi-name>OraGCDDSXA</jndi-name>
      <use-java-context>false</use-java-context>
		<set-tx-query-timeout/>
      <track-connection-by-tx/>
      <isSameRM-override-value>false</isSameRM-override-value>
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
      <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
      <xa-datasource-property name="User">GCD</xa-datasource-property>
      <xa-datasource-property name="Password">xxxx</xa-datasource-property>
      <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
      <no-tx-separate-pools/>
      <metadata>
      <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
          <type-mapping>Oracle9i</type-mapping>
      </metadata>
  </xa-datasource>
</datasources>


We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.

Kind regards.


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

        


From jira-events at lists.jboss.org  Wed Jul  8 19:36:51 2009
From: jira-events at lists.jboss.org (Konstantin Pupkov (JIRA))
Date: Wed, 8 Jul 2009 19:36:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1844137623.1247096211488.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Konstantin Pupkov updated JBMESSAGING-1681:
-------------------------------------------

    Attachment: mdb-with-error.zip


Please take a look on my sample. I rework it based on original mdb sample from ejb3-tutorial

> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Tim Fox
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 22:51:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 8 Jul 2009 22:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1844951510.1247107889768.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1681:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 22:53:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 8 Jul 2009 22:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1666336372.1247108009152.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1681:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 23:19:43 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 8 Jul 2009 23:19:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7087) Remove AS references
 to legacy bootstrap in src/assembly/shutdown.xml
Message-ID: <1433546294.1247109583232.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Remove AS references to legacy bootstrap in src/assembly/shutdown.xml
---------------------------------------------------------------------

                 Key: JBAS-7087
                 URL: https://jira.jboss.org/jira/browse/JBAS-7087
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Build System
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: JBossAS-5.0.2.GA, JBossAS-6.0.0.Alpha1


After the bootstrap projects went to 2.0.0-X, this was left in the wake.  Clean up.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 23:32:29 2009
From: jira-events at lists.jboss.org (Masao Kato (JIRA))
Date: Wed, 8 Jul 2009 23:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1682) duplicate key
 value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
Message-ID: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
---------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1682
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Clustering
    Affects Versions: 1.4.0.SP3.CP07
            Reporter: Masao Kato
            Assignee: Tim Fox



NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 

When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 


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

        


From jira-events at lists.jboss.org  Wed Jul  8 23:34:29 2009
From: jira-events at lists.jboss.org (Masao Kato (JIRA))
Date: Wed, 8 Jul 2009 23:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1347189770.1247110469915.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475545#action_12475545 ] 

Masao Kato commented on JBMESSAGING-1682:
-----------------------------------------

Generated log:

2009-07-07 14:05:27,300 WARN  [org.jboss.messaging.core.impl.JDBCSupport] SQLException caught, SQLState 23505 code:0- assuming deadlock detected, try:1
org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "jbm_msg_pkey"
	at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1608)
	at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1343)
	at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:194)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:451)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:350)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:304)
	at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:278)
	at org.jboss.messaging.core.impl.JDBCPersistenceManager$1AddReferenceRunner.doTransaction(JDBCPersistenceManager.java:1357)
	at org.jboss.messaging.core.impl.JDBCSupport$JDBCTxRunner2.execute(JDBCSupport.java:474)
	at org.jboss.messaging.core.impl.JDBCSupport$JDBCTxRunner2.executeWithRetry(JDBCSupport.java:512)
	at org.jboss.messaging.core.impl.JDBCPersistenceManager.addReference(JDBCPersistenceManager.java:1408)
	at org.jboss.messaging.core.impl.ChannelSupport.handle(ChannelSupport.java:227)
	at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.routeInternal(MessagingPostOffice.java:2212)
	at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.route(MessagingPostOffice.java:499)
	at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:755)
	at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:399)
	at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:87)
	at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_7280680627620114891.invokeNext(SessionAdvised$send_7280680627620114891.java)
	at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:157)
	at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121)
	at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_7280680627620114891.invokeNext(SessionAdvised$send_7280680627620114891.java)
	at org.jboss.jms.server.endpoint.advised.SessionAdvised.send(SessionAdvised.java)
	at org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(SessionSendRequest.java:95)
	at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:866)
	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:608)
	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:420)
	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:173)
2009-07-07 14:05:27,301 WARN  [org.jboss.messaging.core.impl.JDBCSupport] Trying again after a pause


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Masao Kato
>            Assignee: Tim Fox
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Wed Jul  8 23:34:30 2009
From: jira-events at lists.jboss.org (Masao Kato (JIRA))
Date: Wed, 8 Jul 2009 23:34:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <134979799.1247110470357.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475546#action_12475546 ] 

Masao Kato commented on JBMESSAGING-1682:
-----------------------------------------

A source code to seem to be a problem

org.jboss.messaging.core.impl.RotatingID.java
   public synchronized long getID()
   {
      long id1 = nodeID << 54;

      long id2 = System.currentTimeMillis() << 14;

      long id = id1 | id2 | count;

      if (count == Short.MAX_VALUE)
      {
         count = 0;

         long now = System.currentTimeMillis();

         //Safety - not likely to happen

         while (now == lastTime)
         {
            try
            {
               Thread.sleep(1);
            }
            catch (InterruptedException e)
            {}

            now = System.currentTimeMillis();
         }

         lastTime = now;
      }
      else
      {
         count++;
      }

      return id;
   }


I think that the position of the shift of the bit is strange. 
I understand that the same message ID is generated with the same count value at the same time when I carry out the following message ID generation sample programs.

public class MsgIDTest {

	public static void main(String[] args) {
		

	      long tmptime = System.currentTimeMillis();

	      for (long i = 0; i <255; i++) {
		      printId(i,tmptime,(short)(Short.MAX_VALUE-1));
			
	      }
	      

	}

	
	static public void printId(long nodeID, long time, short count) {
		

        System.out.println("    nodeID:" + Long.toString(nodeID));
		System.out.println("        ms:" + Long.toBinaryString(time));

		//generate id
		long id1 = nodeID << 54;

		long id2 = time << 14;

		long id = id1 | id2 | count;

		System.out.println("     MsgID:" + Long.toString(id));

		System.out.println("==Binary=");

		System.out.println("    nodeID:" + Long.toBinaryString(nodeID));
		System.out.println("nodeID<<54:" + Long.toBinaryString(id1));
		System.out.println("    ms<<14:" + Long.toBinaryString(id2));
		System.out.println("     MsgID:" + Long.toBinaryString(id));
		System.out.println("");

	}
	
	
}

output:
    nodeID:0
        ms:10010001001011101100010000101011011100010
     MsgID:20432645850169344
==Binary=
    nodeID:0
nodeID<<54:0
    ms<<14:1001000100101110110001000010101101110001000000000000000
     MsgID:1001000100101110110001000010101101110001000000000000000

    nodeID:1
        ms:10010001001011101100010000101011011100010
     MsgID:20432645850169344
==Binary=
    nodeID:1
nodeID<<54:1000000000000000000000000000000000000000000000000000000
    ms<<14:1001000100101110110001000010101101110001000000000000000
     MsgID:1001000100101110110001000010101101110001000000000000000

    nodeID:2
        ms:10010001001011101100010000101011011100010
     MsgID:56461442869133312
==Binary=
    nodeID:10
nodeID<<54:10000000000000000000000000000000000000000000000000000000
    ms<<14:1001000100101110110001000010101101110001000000000000000
     MsgID:11001000100101110110001000010101101110001000000000000000

    nodeID:3
        ms:10010001001011101100010000101011011100010
     MsgID:56461442869133312
==Binary=
    nodeID:11
nodeID<<54:11000000000000000000000000000000000000000000000000000000
    ms<<14:1001000100101110110001000010101101110001000000000000000
     MsgID:11001000100101110110001000010101101110001000000000000000


Workaround:
Don't use an ID number next to each other node ID in the cluster.


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Masao Kato
>            Assignee: Tim Fox
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Wed Jul  8 23:41:41 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 8 Jul 2009 23:41:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-96) Extract
	initialization logic
In-Reply-To: <1674931690.1247002791408.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1461691749.1247110901848.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-96.
---------------------------------------

    Resolution: Done


> Extract initialization logic
> ----------------------------
>
>                 Key: JBBOOT-96
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-96
>             Project: JBoss Bootstrap
>          Issue Type: Task
>          Components: impl-as, impl-base, impl-mc
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 2.0.0-beta-1 
>
>
> With JBBOOT-95 we now have pre/post states for server initialization.  This means that the initialize() method must be marked final such that its logic containing when to fire the state changes cannot be overridden.  We still need to provide a mechanism for subclasses of AbstractServer to carry out their own initialization logic, so extract this into a "doInitialize()", much like we have a "doStart()".

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

        


From jira-events at lists.jboss.org  Wed Jul  8 23:51:30 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 8 Jul 2009 23:51:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1821898179.1247111490016.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475547#action_12475547 ] 

Howard Gao commented on JBMESSAGING-1681:
-----------------------------------------

Hi Konstantin,

I know what the problem is - you didn't call connection.start() before you receive the message. If you don't start the connecton, message will never be delivered to the consumer.

So I'm going to reject this jira.

Howard


> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

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

        


From jira-events at lists.jboss.org  Wed Jul  8 23:53:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 8 Jul 2009 23:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1681) fetch based on
 messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <257058057.1247111609845.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1681.
-----------------------------------

    Resolution: Rejected


rejected as it's not an issue. 

> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 00:47:40 2009
From: jira-events at lists.jboss.org (Konstantin Pupkov (JIRA))
Date: Thu, 9 Jul 2009 00:47:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <867510109.1247114860623.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475549#action_12475549 ] 

Konstantin Pupkov commented on JBMESSAGING-1681:
------------------------------------------------

Yes. You are correct. Then I added cnn.start(). All things works. But that mean your sample is not correct. Please correct example. As far as I rework your example. ejb3-tutorial.....mdb

> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 02:05:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 02:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1667) MBeans cannot
 have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <371258814.1247119529222.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1667.
-----------------------------------

    Resolution: Done


done.

> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 02:28:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 02:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1875422107.1247120909652.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475557#action_12475557 ] 

Howard Gao commented on JBMESSAGING-1681:
-----------------------------------------

Hi can you kindly point me where I can get ejb3-tutorial example and see if it has the problem? Thanks.

Howard


> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 02:58:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 02:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1900495222.1247122709218.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475561#action_12475561 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

Yes, the ID generation algorithm is dubious. The node id field, time field and counter field overlap each other, I believe it is not what it is intended.
It needs to modify the code a bit.
Thanks!


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Masao Kato
>            Assignee: Tim Fox
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Thu Jul  9 03:00:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 03:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <937024290.1247122829362.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1682:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Thu Jul  9 04:28:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Jul 2009 04:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <98617087.1247128109230.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475574#action_12475574 ] 

Tim Fox commented on JBMESSAGING-1682:
--------------------------------------

Can you add more info here why you think the algorithm is wrong. I.e. please post the algorithm and explain why it is wrong. I want to know when this was introduced.

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Thu Jul  9 04:32:29 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Thu, 9 Jul 2009 04:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1679) Could not find
 reference with id
In-Reply-To: <318505980.1246983291590.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1568599893.1247128349434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor closed JBMESSAGING-1679.
------------------------------------

    Resolution: Done


> Could not find reference with id
> --------------------------------
>
>                 Key: JBMESSAGING-1679
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1679
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>            Reporter: Adrian Woodhead
>            Assignee: Andy Taylor
>
> Refer to http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242246#4242246 for more information, stack trace etc.
> In essence the problem seems to be messages with an expiry time set seem to have problems when pre-ack mode is used.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 04:32:29 2009
From: jira-events at lists.jboss.org (Jonathan Halliday (JIRA))
Date: Thu, 9 Jul 2009 04:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
In-Reply-To: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <729867676.1247128349749.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Halliday reassigned JBAS-7086:
---------------------------------------

    Assignee: Jesper Pedersen  (was: Jonathan Halliday)


> Can't enlist in transaction with second Oracle XA connection/resource.
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7086
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager (Arjuna)
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: The operating system has been windows, but that doesn't appear to be related.
> Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
>            Reporter: Kevin Bates
>            Assignee: Jesper Pedersen
>
> We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.
> At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:
> 2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
> oracle.jdbc.xa.OracleXAException
> 	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
> 	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
> 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
> com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
> 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
> 	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
> 	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
> 	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:404)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy134.executeChanges(Unknown Source)
> 	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:378)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy135.executeChanges(Unknown Source)
> 	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
> 	at java.security.AccessController.doPrivileged(AccessController.java:284)
> 	at javax.security.auth.Subject.doAs(Subject.java:573)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
> 	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
> 	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:735)
> Caused by: 
> org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
> 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 	... 90 more
> Caused by: 
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 	... 92 more
> Caused by: 
> javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	... 96 more
> The two XA data sources are configured as follows:
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">OS1</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraGCDDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">GCD</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.
> Kind regards.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 04:38:41 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 04:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <137792606.1247128721530.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475577#action_12475577 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

As of cp08/1.4.4.GA, the RotatingID's algorithm has been changed because of the enlargement of that range of nodeID.

The new structure of a ID is like:

[16 bits node id] + [34 bits time] + [14 bits counter]

However the code is not implementing this structure:

      long id1 = nodeID << 48;

      long id2 = System.currentTimeMillis() << 14;

      long id = id1 | id2 | count;

and the counter is a short type value, it should be 15 bit (minus the highest sign bit).

So we can re-design the structure as:

[16 bits node id] + [33 bits time] + [15 bits counter]

Another issue is how we take the time bits off the system time (a long value). We know the upper bits of the system
changes very slow (it takes a very long time to make the 40th bit increase by one for example). So we should take the lower part.

If we take bit0 (lowest bit) to bit 32, that means for every millisecond, this field will change by one. To make this field have two same value, you need

2^33 milliseconds, that's about 2^33 / 1000 / 3600 / 24 = 99 days.

However, to make two messages have same ID, the first message must keep in the DB for at least 99 days (and for each 99 days interval thereafter). And the second message
must be sent on the 99th day within the same millisecond, and the counter value (third field) needs to be the same as the first one.

Or, in another case, if the sending rate of messages within one node is equal to or greater than 32767 (short.MAX_VALUE) messages per millisecond, and those messages are all stored in DB at the moment,
there is a chance of two messages having identical IDs.






> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Thu Jul  9 04:42:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Jul 2009 04:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2104534679.1247128949410.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475579#action_12475579 ] 

Tim Fox commented on JBMESSAGING-1682:
--------------------------------------

Ouch. Can you also post a link to the JIRA in CP08 where the algorithm got broken.

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Thu Jul  9 04:44:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 04:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1262491920.1247129069205.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475580#action_12475580 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

about the algorithm, we need to clear the higher 16 bits of the time field and also clear the higher 2 bits of the counter before they 'OR'ed together.


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Thu Jul  9 04:46:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 04:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1682) duplicate key
 value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <910989388.1247129189206.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1682:
------------------------------------

        Fix Version/s: 1.4.0.SP3.CP09
                       1.4.5.GA
    Affects Version/s: 1.4.4.GA
                       1.4.0.SP3.CP08


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Thu Jul  9 04:51:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Jul 2009 04:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1682) duplicate key
 value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1796571985.1247129489789.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1682:
---------------------------------

    Priority: Critical  (was: Major)


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Critical
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Thu Jul  9 05:09:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 9 Jul 2009 05:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1865) Upgrade to
 hibernate-core 3.3.1.GA
Message-ID: <15876972.1247130569212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade to hibernate-core 3.3.1.GA
----------------------------------

                 Key: EJBTHREE-1865
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1865
             Project: EJB 3.0
          Issue Type: Thirdparty Change
          Components: core
    Affects Versions: 1.1.8
            Reporter: jaikiran pai
            Assignee: jaikiran pai


Right now the core depends on:

     <dependency>
       <groupId>org.hibernate</groupId>
      <artifactId>hibernate</artifactId>
      <version>3.2.6.ga</version>
     </dependency>

Furthermore, org.hibernate:hibernate is a banned dependency in AS https://jira.jboss.org/jira/browse/JBAS-6904

Move to org.hibernate:hibernate-core 3.3.1.GA


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

        


From jira-events at lists.jboss.org  Thu Jul  9 05:31:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 9 Jul 2009 05:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1865) Upgrade to
 hibernate-core 3.3.1.GA
In-Reply-To: <15876972.1247130569212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <898312962.1247131889087.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1865.
------------------------------------

    Fix Version/s: 1.1.9
       Resolution: Done


> Upgrade to hibernate-core 3.3.1.GA
> ----------------------------------
>
>                 Key: EJBTHREE-1865
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1865
>             Project: EJB 3.0
>          Issue Type: Thirdparty Change
>          Components: core
>    Affects Versions: 1.1.8
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 1.1.9
>
>
> Right now the core depends on:
>      <dependency>
>        <groupId>org.hibernate</groupId>
>       <artifactId>hibernate</artifactId>
>       <version>3.2.6.ga</version>
>      </dependency>
> Furthermore, org.hibernate:hibernate is a banned dependency in AS https://jira.jboss.org/jira/browse/JBAS-6904
> Move to org.hibernate:hibernate-core 3.3.1.GA

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

        


From jira-events at lists.jboss.org  Thu Jul  9 06:43:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 9 Jul 2009 06:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-213) Expose
 SchemaBindingValidator as an interface
Message-ID: <461919193.1247136209578.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Expose SchemaBindingValidator as an interface
---------------------------------------------

                 Key: JBXB-213
                 URL: https://jira.jboss.org/jira/browse/JBXB-213
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Feature Request
    Affects Versions: JBossXB-2.0.2.Beta1
            Reporter: Ales Justin
            Assignee: Ales Justin


Expose current class SchemaBindingValidator as an interface,
moving the current impl to DefaultSchemaBindingValidator.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 07:18:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 9 Jul 2009 07:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBXB-213) Expose
 SchemaBindingValidator as an interface
In-Reply-To: <461919193.1247136209578.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1439789909.1247138309187.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBXB-213.
------------------------------

    Resolution: Done


> Expose SchemaBindingValidator as an interface
> ---------------------------------------------
>
>                 Key: JBXB-213
>                 URL: https://jira.jboss.org/jira/browse/JBXB-213
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>    Affects Versions: JBossXB-2.0.2.Beta1
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>
> Expose current class SchemaBindingValidator as an interface,
> moving the current impl to DefaultSchemaBindingValidator.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 08:10:29 2009
From: jira-events at lists.jboss.org (anil kumar (JIRA))
Date: Thu, 9 Jul 2009 08:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7088) expressions like
 'ne', 'eq' are not working in jboss
Message-ID: <170839805.1247141429138.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

expressions like 'ne','eq' are not working in jboss
---------------------------------------------------

                 Key: JBAS-7088
                 URL: https://jira.jboss.org/jira/browse/JBAS-7088
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JSF
    Affects Versions: JBossAS-5.1.0.GA
         Environment: windows
            Reporter: anil kumar
            Assignee: Stan Silvert


<h:dataTable value="#{HeaderBean.records}" var="screenConfig">
              <h:column rendered="#{screenConfig.displayTitle ne 'dashboard'}">
              <h:outputText  value="#{screenConfig.displayTitle}"> </h:outputText>
               </h:column>
  </h:dataTable>
 expressions like 'ne','eq' are not working in jboss but its working fine in Glassfish.
 please suggest me on fixing this issue.



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

        


From jira-events at lists.jboss.org  Thu Jul  9 08:56:40 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 9 Jul 2009 08:56:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1010) TCPGOSSIP / TUNNEL:
 handle reconnecting on disconnect
Message-ID: <989573753.1247144200896.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

TCPGOSSIP / TUNNEL: handle reconnecting on disconnect
-----------------------------------------------------

                 Key: JGRP-1010
                 URL: https://jira.jboss.org/jira/browse/JGRP-1010
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.8


When a GossipRouter is not running, a RouterStub emits a callback that it failed to connect. The callback should schedule a recurring connect() task, until it succeeds. This should be done in both TUNNEL (done in 2.6.x, but not currently working in 2.8, due to the GR changes) and TCPGOSSIP (not even implemented in 2.6.x !).
The reconnect logic needs to work with shared transports as well.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 08:58:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 9 Jul 2009 08:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1010) TCPGOSSIP /
 TUNNEL: handle reconnecting on disconnect
In-Reply-To: <989573753.1247144200896.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <102426613.1247144309133.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475602#action_12475602 ] 

Bela Ban commented on JGRP-1010:
--------------------------------

If we have 2 GossipRouters A and B configured, and only B is disconnected, we need to make sure A does *not* reconnect again, or that if it does, a duplicate CONNECT message is discarded at the GR.

> TCPGOSSIP / TUNNEL: handle reconnecting on disconnect
> -----------------------------------------------------
>
>                 Key: JGRP-1010
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1010
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> When a GossipRouter is not running, a RouterStub emits a callback that it failed to connect. The callback should schedule a recurring connect() task, until it succeeds. This should be done in both TUNNEL (done in 2.6.x, but not currently working in 2.8, due to the GR changes) and TCPGOSSIP (not even implemented in 2.6.x !).
> The reconnect logic needs to work with shared transports as well.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 09:34:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 9 Jul 2009 09:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-110) Use remotable POJO
	naming server
Message-ID: <337769786.1247146469111.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Use remotable POJO naming server
--------------------------------

                 Key: JBJCA-110
                 URL: https://jira.jboss.org/jira/browse/JBJCA-110
             Project: JBoss JCA
          Issue Type: Task
          Components: Standalone
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Switch to a remotable POJO naming server and allow the user to bind the address via a "-b" startup option.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 09:36:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 9 Jul 2009 09:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-110) Use remotable POJO
	naming server
In-Reply-To: <337769786.1247146469111.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <320114049.1247146589303.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-110.
-----------------------------------

    Resolution: Done


> Use remotable POJO naming server
> --------------------------------
>
>                 Key: JBJCA-110
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-110
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Standalone
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Switch to a remotable POJO naming server and allow the user to bind the address via a "-b" startup option.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 09:45:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 09:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <534634309.1247147129286.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475611#action_12475611 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

The id can be generated using the following modified code:


      long id1 = nodeID << 48;

      long id2 = (System.currentTimeMillis() << 15) & 0x0000FFFFFFFFFFFFL; //reserve the high 16 bits for node id

      long id = id1 | id2 | count;


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Critical
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Thu Jul  9 09:47:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 09:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <637268416.1247147249373.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475612#action_12475612 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

[quote]
Or, in another case, if the sending rate of messages within one node is equal to or greater than 32767 (short.MAX_VALUE) messages per millisecond, and those messages are all stored in DB at the moment,
there is a chance of two messages having identical IDs.
[/quote]

The above case has already been taken care of in the code, so it is eliminated.



> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Critical
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Thu Jul  9 09:51:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 09:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1682) duplicate key
 value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1229577685.1247147489212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1682.
-----------------------------------

    Resolution: Done


Done.

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Critical
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Thu Jul  9 10:14:29 2009
From: jira-events at lists.jboss.org (anil kumar (JIRA))
Date: Thu, 9 Jul 2009 10:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7089) <h:column> level
 rendering is not working in JBOSS
Message-ID: <1328936593.1247148869241.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

<h:column> level rendering is not working in JBOSS 
---------------------------------------------------

                 Key: JBAS-7089
                 URL: https://jira.jboss.org/jira/browse/JBAS-7089
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JSF
    Affects Versions: JBossAS-5.1.0.GA
         Environment: windows
            Reporter: anil kumar
            Assignee: Stan Silvert


<h:column> level rendering is not working in JBOSS but works in Glassfish.

   <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
             <h:column>
             <h:outputText  value="#{screenConfig.displayTitle}"  rendered="#{'5' eq '5'}"> </h:outputText>   
              </h:column>  
         </h:dataTable> 

this is working perfectly.




<h:dataTable value="#{HeaderBean.records}" var="screenConfig">
             <h:column  rendered="#{'5' eq '5'}"> >
             <h:outputText  value="#{screenConfig.displayTitle}" </h:outputText>   
              </h:column>  
         </h:dataTable> 

where as above one is not working. I really don't understand why this is not working in JBOSS.


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

        


From jira-events at lists.jboss.org  Thu Jul  9 10:39:29 2009
From: jira-events at lists.jboss.org (Kit Chan (JIRA))
Date: Thu, 9 Jul 2009 10:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2201) Rule got executed
 even does not satisfy LHS after firing an external event in Flow
In-Reply-To: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <449088057.1247150369309.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kit Chan updated JBRULES-2201:
------------------------------

    Component/s: drools-core (flow)
       Priority: Critical  (was: Major)


> Rule got executed even does not satisfy LHS after firing an external event in Flow
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2201
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert), drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP SP3, Eclipse 3.4.2
>            Reporter: Kit Chan
>            Assignee: Mark Proctor
>            Priority: Critical
>
> I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 11:16:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Jul 2009 11:16:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <238381023.1247152589249.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox reopened JBMESSAGING-1682:
----------------------------------



> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Critical
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Thu Jul  9 11:18:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Jul 2009 11:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1682) duplicate key
 value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <156865431.1247152709233.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1682:
---------------------------------

    Priority: Blocker  (was: Critical)


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Thu Jul  9 11:55:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Thu, 9 Jul 2009 11:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7089) <h:column> level
 rendering is not working in JBOSS
In-Reply-To: <1328936593.1247148869241.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <858302133.1247154929191.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475639#action_12475639 ] 

Stan Silvert commented on JBAS-7089:
------------------------------------

Your second example has an extra > at the end of the column tag.  Fix that first.  If it still fails, post the error.

> <h:column> level rendering is not working in JBOSS 
> ---------------------------------------------------
>
>                 Key: JBAS-7089
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7089
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: windows
>            Reporter: anil kumar
>            Assignee: Stan Silvert
>
> <h:column> level rendering is not working in JBOSS but works in Glassfish.
>    <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
>              <h:column>
>              <h:outputText  value="#{screenConfig.displayTitle}"  rendered="#{'5' eq '5'}"> </h:outputText>   
>               </h:column>  
>          </h:dataTable> 
> this is working perfectly.
> <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
>              <h:column  rendered="#{'5' eq '5'}"> >
>              <h:outputText  value="#{screenConfig.displayTitle}" </h:outputText>   
>               </h:column>  
>          </h:dataTable> 
> where as above one is not working. I really don't understand why this is not working in JBOSS.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 11:57:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Thu, 9 Jul 2009 11:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7089) <h:column> level
 rendering is not working in JBOSS
In-Reply-To: <1328936593.1247148869241.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2101497686.1247155049162.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert updated JBAS-7089:
-------------------------------

    Labels:   (was: column  level rendering is not working in JBOSS )


> <h:column> level rendering is not working in JBOSS 
> ---------------------------------------------------
>
>                 Key: JBAS-7089
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7089
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: windows
>            Reporter: anil kumar
>            Assignee: Stan Silvert
>
> <h:column> level rendering is not working in JBOSS but works in Glassfish.
>    <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
>              <h:column>
>              <h:outputText  value="#{screenConfig.displayTitle}"  rendered="#{'5' eq '5'}"> </h:outputText>   
>               </h:column>  
>          </h:dataTable> 
> this is working perfectly.
> <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
>              <h:column  rendered="#{'5' eq '5'}"> >
>              <h:outputText  value="#{screenConfig.displayTitle}" </h:outputText>   
>               </h:column>  
>          </h:dataTable> 
> where as above one is not working. I really don't understand why this is not working in JBOSS.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 12:01:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Thu, 9 Jul 2009 12:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7089) <h:column> level
 rendering is not working in JBOSS
In-Reply-To: <1328936593.1247148869241.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1882705085.1247155289147.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475640#action_12475640 ] 

Stan Silvert commented on JBAS-7089:
------------------------------------

Your outputText tag is also invalid.

> <h:column> level rendering is not working in JBOSS 
> ---------------------------------------------------
>
>                 Key: JBAS-7089
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7089
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: windows
>            Reporter: anil kumar
>            Assignee: Stan Silvert
>
> <h:column> level rendering is not working in JBOSS but works in Glassfish.
>    <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
>              <h:column>
>              <h:outputText  value="#{screenConfig.displayTitle}"  rendered="#{'5' eq '5'}"> </h:outputText>   
>               </h:column>  
>          </h:dataTable> 
> this is working perfectly.
> <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
>              <h:column  rendered="#{'5' eq '5'}"> >
>              <h:outputText  value="#{screenConfig.displayTitle}" </h:outputText>   
>               </h:column>  
>          </h:dataTable> 
> where as above one is not working. I really don't understand why this is not working in JBOSS.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 12:20:40 2009
From: jira-events at lists.jboss.org (Rinat Gareev (JIRA))
Date: Thu, 9 Jul 2009 12:20:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1866) EJB deployer
 require mapped name for SessionContext injection
Message-ID: <1953202672.1247156440396.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

EJB deployer require mapped name for SessionContext injection
-------------------------------------------------------------

                 Key: EJBTHREE-1866
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1866
             Project: EJB 3.0
          Issue Type: Bug
          Components: core
    Affects Versions: 1.1.5
            Reporter: Rinat Gareev


EJB deployer require mapped name for SessionContext injection

EJB class:

@Stateful
@EJBs
		({
				@EJB (beanInterface = CoreSecurityFacade.class, beanName = "CoreSecurityFacadeBean",
						name = "ejb/CoreSecurityFacade"),
				@EJB (beanInterface = CoreApplicationsFacade.class, beanName = "CoreApplicationsFacadeBean",
						name = "ejb/CoreApplicationsFacade"),
				@EJB (beanInterface = CoreConfigFacade.class, beanName = "CoreConfigFacadeBean",
						name = "ejb/CoreConfigFacade")
		})
public class CoreFacadeFactoryBean implements CoreFacadeFactory, Serializable
{
	@Resource
	private SessionContext ctx;
....content omitted
}

Root cause:

Caused by: java.lang.RuntimeException: You did not specify a @Resource.mappedName() on private javax.ejb.SessionContext rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean.ctx and there is no binding for enc name env/rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean/ctx in XML                                                                                 
        at org.jboss.injection.ResourceHandler.handlePropertyAnnotation(ResourceHandler.java:684)                                                                                   
        at org.jboss.injection.ResourceHandler.handleFieldAnnotations(ResourceHandler.java:497)                                                                                     
        at org.jboss.injection.InjectionUtil.processFieldAnnotations(InjectionUtil.java:160)                                                                                        
        at org.jboss.injection.InjectionUtil.processAnnotations(InjectionUtil.java:197)                                                                                             
        at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:590)                                                                                                       
        at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
        at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
        ... 35 more


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

        


From jira-events at lists.jboss.org  Thu Jul  9 12:22:29 2009
From: jira-events at lists.jboss.org (Rinat Gareev (JIRA))
Date: Thu, 9 Jul 2009 12:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1866) EJB deployer
 requires mapped name for SessionContext injection
In-Reply-To: <1953202672.1247156440396.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <585540093.1247156549112.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rinat Gareev updated EJBTHREE-1866:
-----------------------------------

        Summary: EJB deployer requires mapped name for SessionContext injection  (was: EJB deployer require mapped name for SessionContext injection)
    Environment: JBoss 5.1.0 GA


> EJB deployer requires mapped name for SessionContext injection
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-1866
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1866
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>         Environment: JBoss 5.1.0 GA
>            Reporter: Rinat Gareev
>
> EJB deployer require mapped name for SessionContext injection
> EJB class:
> @Stateful
> @EJBs
> 		({
> 				@EJB (beanInterface = CoreSecurityFacade.class, beanName = "CoreSecurityFacadeBean",
> 						name = "ejb/CoreSecurityFacade"),
> 				@EJB (beanInterface = CoreApplicationsFacade.class, beanName = "CoreApplicationsFacadeBean",
> 						name = "ejb/CoreApplicationsFacade"),
> 				@EJB (beanInterface = CoreConfigFacade.class, beanName = "CoreConfigFacadeBean",
> 						name = "ejb/CoreConfigFacade")
> 		})
> public class CoreFacadeFactoryBean implements CoreFacadeFactory, Serializable
> {
> 	@Resource
> 	private SessionContext ctx;
> ....content omitted
> }
> Root cause:
> Caused by: java.lang.RuntimeException: You did not specify a @Resource.mappedName() on private javax.ejb.SessionContext rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean.ctx and there is no binding for enc name env/rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean/ctx in XML                                                                                 
>         at org.jboss.injection.ResourceHandler.handlePropertyAnnotation(ResourceHandler.java:684)                                                                                   
>         at org.jboss.injection.ResourceHandler.handleFieldAnnotations(ResourceHandler.java:497)                                                                                     
>         at org.jboss.injection.InjectionUtil.processFieldAnnotations(InjectionUtil.java:160)                                                                                        
>         at org.jboss.injection.InjectionUtil.processAnnotations(InjectionUtil.java:197)                                                                                             
>         at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:590)                                                                                                       
>         at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
>         at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
>         ... 35 more

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

        


From jira-events at lists.jboss.org  Thu Jul  9 12:24:29 2009
From: jira-events at lists.jboss.org (Rinat Gareev (JIRA))
Date: Thu, 9 Jul 2009 12:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1866) EJB deployer
 requires mapped name for SessionContext injection
In-Reply-To: <1953202672.1247156440396.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1414793665.1247156669077.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rinat Gareev updated EJBTHREE-1866:
-----------------------------------

    Attachment: server.log


server.log content for EAR deploying time

> EJB deployer requires mapped name for SessionContext injection
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-1866
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1866
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>         Environment: JBoss 5.1.0 GA
>            Reporter: Rinat Gareev
>         Attachments: server.log
>
>
> EJB deployer require mapped name for SessionContext injection
> EJB class:
> @Stateful
> @EJBs
> 		({
> 				@EJB (beanInterface = CoreSecurityFacade.class, beanName = "CoreSecurityFacadeBean",
> 						name = "ejb/CoreSecurityFacade"),
> 				@EJB (beanInterface = CoreApplicationsFacade.class, beanName = "CoreApplicationsFacadeBean",
> 						name = "ejb/CoreApplicationsFacade"),
> 				@EJB (beanInterface = CoreConfigFacade.class, beanName = "CoreConfigFacadeBean",
> 						name = "ejb/CoreConfigFacade")
> 		})
> public class CoreFacadeFactoryBean implements CoreFacadeFactory, Serializable
> {
> 	@Resource
> 	private SessionContext ctx;
> ....content omitted
> }
> Root cause:
> Caused by: java.lang.RuntimeException: You did not specify a @Resource.mappedName() on private javax.ejb.SessionContext rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean.ctx and there is no binding for enc name env/rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean/ctx in XML                                                                                 
>         at org.jboss.injection.ResourceHandler.handlePropertyAnnotation(ResourceHandler.java:684)                                                                                   
>         at org.jboss.injection.ResourceHandler.handleFieldAnnotations(ResourceHandler.java:497)                                                                                     
>         at org.jboss.injection.InjectionUtil.processFieldAnnotations(InjectionUtil.java:160)                                                                                        
>         at org.jboss.injection.InjectionUtil.processAnnotations(InjectionUtil.java:197)                                                                                             
>         at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:590)                                                                                                       
>         at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
>         at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
>         ... 35 more

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

        


From jira-events at lists.jboss.org  Thu Jul  9 12:26:29 2009
From: jira-events at lists.jboss.org (Rinat Gareev (JIRA))
Date: Thu, 9 Jul 2009 12:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1866) EJB deployer
 requires mapped name for SessionContext injection
In-Reply-To: <1953202672.1247156440396.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <641648487.1247156789127.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rinat Gareev updated EJBTHREE-1866:
-----------------------------------

    Attachment: ejb-jar.xml


ejb-jar.xml of according EJB module

> EJB deployer requires mapped name for SessionContext injection
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-1866
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1866
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>         Environment: JBoss 5.1.0 GA
>            Reporter: Rinat Gareev
>         Attachments: ejb-jar.xml, server.log
>
>
> EJB deployer require mapped name for SessionContext injection
> EJB class:
> @Stateful
> @EJBs
> 		({
> 				@EJB (beanInterface = CoreSecurityFacade.class, beanName = "CoreSecurityFacadeBean",
> 						name = "ejb/CoreSecurityFacade"),
> 				@EJB (beanInterface = CoreApplicationsFacade.class, beanName = "CoreApplicationsFacadeBean",
> 						name = "ejb/CoreApplicationsFacade"),
> 				@EJB (beanInterface = CoreConfigFacade.class, beanName = "CoreConfigFacadeBean",
> 						name = "ejb/CoreConfigFacade")
> 		})
> public class CoreFacadeFactoryBean implements CoreFacadeFactory, Serializable
> {
> 	@Resource
> 	private SessionContext ctx;
> ....content omitted
> }
> Root cause:
> Caused by: java.lang.RuntimeException: You did not specify a @Resource.mappedName() on private javax.ejb.SessionContext rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean.ctx and there is no binding for enc name env/rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean/ctx in XML                                                                                 
>         at org.jboss.injection.ResourceHandler.handlePropertyAnnotation(ResourceHandler.java:684)                                                                                   
>         at org.jboss.injection.ResourceHandler.handleFieldAnnotations(ResourceHandler.java:497)                                                                                     
>         at org.jboss.injection.InjectionUtil.processFieldAnnotations(InjectionUtil.java:160)                                                                                        
>         at org.jboss.injection.InjectionUtil.processAnnotations(InjectionUtil.java:197)                                                                                             
>         at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:590)                                                                                                       
>         at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
>         at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
>         ... 35 more

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

        


From jira-events at lists.jboss.org  Thu Jul  9 12:31:40 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Jul 2009 12:31:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <177593462.1247157100984.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475643#action_12475643 ] 

Tim Fox commented on JBMESSAGING-1682:
--------------------------------------

I re-opened this because Howard's latest fix only allows 33 bits for the time component:

16 bits node id + 32 bits time + 14 bits counter.

This only allows dates up to:

(2^33-1)/1000/60/60/24/365.25 years since Jan 1 1970, which is only a few months!!

So this is clearly broken still. We cannot allow collisions within a reasonable time range (say 100 years or so).

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Thu Jul  9 12:39:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Jul 2009 12:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <565747844.1247157569225.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475645#action_12475645 ] 

Tim Fox commented on JBMESSAGING-1682:
--------------------------------------

Correction, it's 34 bits for time

So that's (2^35-1)/1000/60/60/24/365.25 = which is just over 1 year sine 1 Jan 1970. Still not enough

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Thu Jul  9 13:43:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 9 Jul 2009 13:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1866) EJB deployer
 requires mapped name for SessionContext injection
In-Reply-To: <1953202672.1247156440396.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <547864575.1247161409149.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475654#action_12475654 ] 

jaikiran pai commented on EJBTHREE-1866:
----------------------------------------

It works fine for me. Can you attach the application which is failing? Also are you packaging any jar containing javax.ejb.* in your application? If yes remove those jars and try it out.

> EJB deployer requires mapped name for SessionContext injection
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-1866
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1866
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>         Environment: JBoss 5.1.0 GA
>            Reporter: Rinat Gareev
>         Attachments: ejb-jar.xml, server.log
>
>
> EJB deployer require mapped name for SessionContext injection
> EJB class:
> @Stateful
> @EJBs
> 		({
> 				@EJB (beanInterface = CoreSecurityFacade.class, beanName = "CoreSecurityFacadeBean",
> 						name = "ejb/CoreSecurityFacade"),
> 				@EJB (beanInterface = CoreApplicationsFacade.class, beanName = "CoreApplicationsFacadeBean",
> 						name = "ejb/CoreApplicationsFacade"),
> 				@EJB (beanInterface = CoreConfigFacade.class, beanName = "CoreConfigFacadeBean",
> 						name = "ejb/CoreConfigFacade")
> 		})
> public class CoreFacadeFactoryBean implements CoreFacadeFactory, Serializable
> {
> 	@Resource
> 	private SessionContext ctx;
> ....content omitted
> }
> Root cause:
> Caused by: java.lang.RuntimeException: You did not specify a @Resource.mappedName() on private javax.ejb.SessionContext rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean.ctx and there is no binding for enc name env/rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean/ctx in XML                                                                                 
>         at org.jboss.injection.ResourceHandler.handlePropertyAnnotation(ResourceHandler.java:684)                                                                                   
>         at org.jboss.injection.ResourceHandler.handleFieldAnnotations(ResourceHandler.java:497)                                                                                     
>         at org.jboss.injection.InjectionUtil.processFieldAnnotations(InjectionUtil.java:160)                                                                                        
>         at org.jboss.injection.InjectionUtil.processAnnotations(InjectionUtil.java:197)                                                                                             
>         at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:590)                                                                                                       
>         at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
>         at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
>         ... 35 more

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

        


From jira-events at lists.jboss.org  Thu Jul  9 14:44:29 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Thu, 9 Jul 2009 14:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6936) Testsuite fails
 during
 tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
In-Reply-To: <368622.1242662765255.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <668424109.1247165069260.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6936:
---------------------------------

    Attachment: threadDump.html


Thread dump taken when server failed to restart.  Also reproducable on trunk.

> Testsuite fails during tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6936
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6936
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: threadDump.html
>
>
> The AS fails to start for the second time during the tests-profileservice target of the testsuite. This is caused by the first instance not being properly shutdown by the following ant command: <server:stop name="profileservice"/>

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

        


From jira-events at lists.jboss.org  Thu Jul  9 15:06:29 2009
From: jira-events at lists.jboss.org (Irena Shaigorodsky (JIRA))
Date: Thu, 9 Jul 2009 15:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7090)
 org.jboss.jdbc.DerbyDatabase used
 by varia example has a bug and never attempts to shut down derby database
Message-ID: <627780683.1247166389107.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

org.jboss.jdbc.DerbyDatabase used by varia example has a bug and never attempts to shut down derby database
-----------------------------------------------------------------------------------------------------------

                 Key: JBAS-7090
                 URL: https://jira.jboss.org/jira/browse/JBAS-7090
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-4.0.5.GA
         Environment: JBoss 4.0.5.GA and JBoss 4.2.3.GA
            Reporter: Irena Shaigorodsky


org.jboss.jdbc.DerbyDatabase used by varia example has a following bug. 
1. connection member is created at service start-up
2. getConnection(String dbURL) creates new connection only if connection member is null
3. on service shut down when getConnection("jdbc:derby:;shutdown=true"); is called nothing happens and Derby is not brought down.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 16:49:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 9 Jul 2009 16:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1607242517.1247172569213.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBAS-7049:
--------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242715


> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

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

        


From jira-events at lists.jboss.org  Thu Jul  9 17:24:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 9 Jul 2009 17:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2202) Generated types
 should be Serializable
Message-ID: <1963762277.1247174669126.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Generated types should be Serializable
--------------------------------------

                 Key: JBRULES-2202
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2202
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler, drools-core
    Affects Versions: 5.0.1.FINAL, 5.0.0.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


Hello,

Recently I've been working with Drools version 5.0.1 to set up an event processor.  While doing so I have come
across difficulties with the accumulate function, in that it will always throw a ClassCastException
when inserting events that are declared within my drl file.  To illustrate this I've set up an example which is
shown below.  I've search Google and the mailing list for several hours, but the only way past this problem
appears to be that I will have to declare a class externally and make sure it implements Serializable.  Does
anyone has suggestions for another approach?  Secondly, I would have assumed that since Drools was
compiling these internally declared classes, that Serializable would have been implemented automatically.  So
is this a result of the generated class not implementing Serializable, or have I missed something in my rules
file?  Thanks.

The important part of my drl file is:

declare TestEvent
   @role( event )
   @expires(10s)
   id : String
end

#This rule works fine when 'Accumulate Count' is commented out, and is used to make
#sure that the event inserting has worked.
rule "Is It There"
    when
        TestEvent() from entry-point "test"
    then
        System.out.println("Found a TestEvent.");
end

#This rule throws a ClassCastException when a TestEvent is inserted.
rule "Accumulate Count"
    when
        $n : Number() from accumulate($t : TestEvent() from entry-point "test",    count($t))
    then
        System.out.println("Found " + $n + " events.");
end

The unit test does this:

FactType testEventType = session.getKnowledgeBase().getFactType("com.drools.test", "TestEvent");
for(int i = 0; i < 10; i++){
    Object testEvent = testEventType.newInstance();
    testEventType.set(testEvent, "id", "id");
    WorkingMemoryEntryPoint mainStream = session.getWorkingMemoryEntryPoint("test");
    mainStream.insert(event);
    session.fireAllRules();
}

The exception I receive is:

org.drools.RuntimeDroolsException: java.lang.ClassCastException: com.drools.test.TestEvent cannot be cast to java.io.Serializable
    at org.drools.rule.Accumulate.accumulate(Accumulate.java:172)
    at org.drools.reteoo.AccumulateNode.modifyTuple(AccumulateNode.java:424)
    at org.drools.reteoo.AccumulateNode.assertObject(AccumulateNode.java:284)
    at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:42)
    at org.drools.reteoo.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:326)
    at org.drools.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:221)
    at org.drools.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:394)
    at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1486)
    at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:158)
    at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:122)
    at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:80)
    at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:28)
    at com.drools.test.MyUnitTest.testEvents(EvaluationTest.java:66)
    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.springframework.test.context.junit4.SpringTestMethod.invoke(SpringTestMethod.java:160)
    at org.springframework.test.context.junit4.SpringMethodRoadie.runTestMethod(SpringMethodRoadie.java:233)
    at org.springframework.test.context.junit4.SpringMethodRoadie$RunBeforesThenTestThenAfters.run(SpringMethodRoadie.java:333)
    at org.springframework.test.context.junit4.SpringMethodRoadie.runWithRepetitions(SpringMethodRoadie.java:217)
    at org.springframework.test.context.junit4.SpringMethodRoadie.runTest(SpringMethodRoadie.java:197)
    at org.springframework.test.context.junit4.SpringMethodRoadie.run(SpringMethodRoadie.java:143)
    at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.invokeTestMethod(SpringJUnit4ClassRunner.java:160)
    at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
    at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
    at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
    at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
    at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
    at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:97)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
    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)
Caused by: java.lang.ClassCastException: com.drools.test.TestEvent cannot be cast to java.io.Serializable
    at org.drools.base.accumulators.JavaAccumulatorFunctionExecutor.accumulate(JavaAccumulatorFunctionExecutor.java:110)
    at org.drools.rule.Accumulate.accumulate(Accumulate.java:164)
    ... 36 more


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

        


From jira-events at lists.jboss.org  Thu Jul  9 17:36:29 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Thu, 9 Jul 2009 17:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6936) Testsuite fails
 during
 tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
In-Reply-To: <368622.1242662765255.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <766635278.1247175389112.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6936:
---------------------------------


After looking at the thread dump, it looks like this is related to  a RichFaces bug, https://jira.jboss.org/jira/browse/RF-4537.
The tests-profileservice target also runs the org.jboss.deployers.seam tests.  During the run, two tests fail due to timeout:
org.jboss.test.deployers.seam.test.SeamBookingExampleUnitTestCase FAILED (timeout)
org.jboss.test.deployers.seam.test.SeamJpaExampleUnitTestCase FAILED (timeout)

The RichFaces bug is marked FIXED with RichFaces 3.3.0.GA.  The version of RichFaces packaged in these test archives is 3.2.2.GA.
I'll verify this by updating the test jars to 3.3.0/3.3.1.
See also: https://jira.jboss.org/jira/browse/JBSEAM-3570

> Testsuite fails during tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6936
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6936
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: threadDump.html
>
>
> The AS fails to start for the second time during the tests-profileservice target of the testsuite. This is caused by the first instance not being properly shutdown by the following ant command: <server:stop name="profileservice"/>

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

        


From jira-events at lists.jboss.org  Thu Jul  9 17:59:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 9 Jul 2009 17:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <304129068.1247176769211.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475676#action_12475676 ] 

Anil Saldhana commented on JBAS-7049:
-------------------------------------

OpenJDK6 bug which has been fixed in OpenJDK7.  The forum thread has the details.

> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

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

        


From jira-events at lists.jboss.org  Thu Jul  9 18:27:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 9 Jul 2009 18:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1676550187.1247178449286.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475682#action_12475682 ] 

Anil Saldhana commented on JBAS-7049:
-------------------------------------

DML has created an issue in iced tea: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=364

> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

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

        


From jira-events at lists.jboss.org  Thu Jul  9 18:36:29 2009
From: jira-events at lists.jboss.org (Konstantin Pupkov (JIRA))
Date: Thu, 9 Jul 2009 18:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <712267433.1247178989210.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475683#action_12475683 ] 

Konstantin Pupkov commented on JBMESSAGING-1681:
------------------------------------------------

here is link: http://www.jboss.org/ejb3/docs.html

search for "Tutorials (Source)" section. 
Then download source in zip archive. In source follow by "/ejb3-tutorials/source/mdb/" path.

> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 19:57:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 9 Jul 2009 19:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-1141) HTTPUnMarshaller
 should test for
 "non-text" content-type instead of "binary" content-type
Message-ID: <1486017658.1247183849135.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

HTTPUnMarshaller should test for "non-text" content-type instead of "binary" content-type
-----------------------------------------------------------------------------------------

                 Key: JBREM-1141
                 URL: https://jira.jboss.org/jira/browse/JBREM-1141
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.3, 2.5.1 (Flounder)
            Reporter: Ron Sigal
            Assignee: Ron Sigal
             Fix For: 2.5.2 (Flounder), 2.2.3.SP1


As an efficiency measure, org.jboss.marshal.http.HTTPUnMarshaller.read() incorporates special handling for strings to avoid serialization.  However, there is a flaw in the logic.

HTTPUnMarshaller.read() calls isBinaryData() and calls super.read() if the return value is true.  If the return value is false, then it processes the input as String data.  Originally, this distinction worked because the only two types recognized were org.jboss.remoting..transport.web.WebUtil.HTML ("text/html") and WebUtil.BINARY ("application/octet-stream").  However, JBREM-653 "allow user to set content-type for http responses" allows the introduction of other content types.

Instead of testing for "application/octet-stream", HTTPUnMarshaller.read() should treat any content type that starts "text" as a String, and it should treat anything else as an object.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 22:52:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 9 Jul 2009 22:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-1142) Clarify use of
 "clientConnectAddress" in RemotingGuide
Message-ID: <1414608541.1247194349236.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Clarify use of "clientConnectAddress" in RemotingGuide
------------------------------------------------------

                 Key: JBREM-1142
                 URL: https://jira.jboss.org/jira/browse/JBREM-1142
             Project: JBoss Remoting
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: docs
    Affects Versions: 2.2.3, 2.5.1 (Flounder)
            Reporter: Ron Sigal
            Assignee: Ron Sigal
             Fix For: 2.5.2 (Flounder), 2.2.3.SP1


The Remoting Guide should spell out the fact that the parameter "clientConnectAddress" is useful only in the context of server side configuration.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 23:04:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 9 Jul 2009 23:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCL-109) Infinite loop when a
 legit LinkageError occurs
Message-ID: <157425770.1247195069114.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Infinite loop when a legit LinkageError occurs
----------------------------------------------

                 Key: JBCL-109
                 URL: https://jira.jboss.org/jira/browse/JBCL-109
             Project: JBoss ClassLoader
          Issue Type: Bug
            Reporter: Jason T. Greene
            Priority: Blocker
             Fix For: JBossCL.2.0.7.GA


To fix an old JVM issue, linkage errors are treated like a ClassCircularityException. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-5327), an infinite loop results. 

synchronized int incrementNumCCE()
 {
     return numCCE;;
  }

This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP


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

        


From jira-events at lists.jboss.org  Thu Jul  9 23:06:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 9 Jul 2009 23:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCL-109) Infinite loop when a
 legit LinkageError occurs
In-Reply-To: <157425770.1247195069114.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1187491261.1247195189644.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBCL-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene updated JBCL-109:
---------------------------------

    Component/s: ClassLoader


> Infinite loop when a legit LinkageError occurs
> ----------------------------------------------
>
>                 Key: JBCL-109
>                 URL: https://jira.jboss.org/jira/browse/JBCL-109
>             Project: JBoss ClassLoader
>          Issue Type: Bug
>          Components: ClassLoader
>            Reporter: Jason T. Greene
>            Priority: Blocker
>             Fix For: JBossCL.2.0.7.GA
>
>
> To fix an old JVM issue, linkage errors are treated like a ClassCircularityException. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-6327), an infinite loop results. 
> synchronized int incrementNumCCE()
>  {
>      return numCCE;;
>   }
> This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP

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

        


From jira-events at lists.jboss.org  Thu Jul  9 23:06:30 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 9 Jul 2009 23:06:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6327) Servlet hangs in
	classloader
In-Reply-To: <11803824.1229509077422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <134294766.1247195190258.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene reassigned JBAS-6327:
-------------------------------------

    Assignee: Jason T. Greene  (was: Emanuel Muckenhuber)


> Servlet hangs in classloader
> ----------------------------
>
>                 Key: JBAS-6327
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6327
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Testsuite ejb3/servlet
>            Reporter: Carlo de Wolf
>            Assignee: Jason T. Greene
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> "http-localhost%2F127.0.0.1-8080-1" daemon prio=1 tid=0x10ae3118 nid=0x6b36 runnable [0x7897c000..0x7897df20]
> 	at java.lang.ClassLoader.defineClass1(Native Method)
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:62)
> 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:509)
> 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:469)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:467)
> 	- locked <0x9a2ff1a8> (a org.jboss.classloader.spi.base.BaseClassLoader)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:444)
> 	at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
> 	at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
> 	at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
> 	at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:254)
> 	at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:148)
> 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:256)
> 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1099)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:735)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:378)
> 	- locked <0x9a2ff1a8> (a org.jboss.classloader.spi.base.BaseClassLoader)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
> 	- locked <0x9a757fb8> (a org.jboss.web.tomcat.service.WebCtxLoader$ENCLoader)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> 	- locked <0x9a757fb8> (a org.jboss.web.tomcat.service.WebCtxLoader$ENCLoader)
> 	at $Proxy156.getWarTestObject(Unknown Source)
> 	at org.jboss.ejb3.test.servlet.servlets.EJBServlet.processRequest(EJBServlet.java:95)
> 	at org.jboss.ejb3.test.servlet.servlets.EJBServlet.doGet(EJBServlet.java:146)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 23:06:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 9 Jul 2009 23:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCL-109) Infinite loop when a
 legit LinkageError occurs
In-Reply-To: <157425770.1247195069114.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1285636296.1247195189580.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBCL-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene updated JBCL-109:
---------------------------------

    Description: 
To fix an old JVM issue, linkage errors are treated like a ClassCircularityException. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-6327), an infinite loop results. 

synchronized int incrementNumCCE()
 {
     return numCCE;;
  }

This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP


  was:
To fix an old JVM issue, linkage errors are treated like a ClassCircularityException. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-5327), an infinite loop results. 

synchronized int incrementNumCCE()
 {
     return numCCE;;
  }

This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP




> Infinite loop when a legit LinkageError occurs
> ----------------------------------------------
>
>                 Key: JBCL-109
>                 URL: https://jira.jboss.org/jira/browse/JBCL-109
>             Project: JBoss ClassLoader
>          Issue Type: Bug
>          Components: ClassLoader
>            Reporter: Jason T. Greene
>            Priority: Blocker
>             Fix For: JBossCL.2.0.7.GA
>
>
> To fix an old JVM issue, linkage errors are treated like a ClassCircularityException. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-6327), an infinite loop results. 
> synchronized int incrementNumCCE()
>  {
>      return numCCE;;
>   }
> This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP

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

        


From jira-events at lists.jboss.org  Thu Jul  9 23:06:30 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 9 Jul 2009 23:06:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6327) Servlet hangs in
	classloader
In-Reply-To: <11803824.1229509077422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <306492186.1247195190019.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475687#action_12475687 ] 

Jason T. Greene commented on JBAS-6327:
---------------------------------------

The hang is caused by JBCL-109, which is a bad reaction to a linkage error. The linkage error is caused by a packaging problem in the test.

> Servlet hangs in classloader
> ----------------------------
>
>                 Key: JBAS-6327
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6327
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Testsuite ejb3/servlet
>            Reporter: Carlo de Wolf
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> "http-localhost%2F127.0.0.1-8080-1" daemon prio=1 tid=0x10ae3118 nid=0x6b36 runnable [0x7897c000..0x7897df20]
> 	at java.lang.ClassLoader.defineClass1(Native Method)
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:62)
> 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:509)
> 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:469)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:467)
> 	- locked <0x9a2ff1a8> (a org.jboss.classloader.spi.base.BaseClassLoader)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:444)
> 	at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
> 	at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
> 	at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
> 	at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:254)
> 	at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:148)
> 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:256)
> 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1099)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:735)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:378)
> 	- locked <0x9a2ff1a8> (a org.jboss.classloader.spi.base.BaseClassLoader)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
> 	- locked <0x9a757fb8> (a org.jboss.web.tomcat.service.WebCtxLoader$ENCLoader)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> 	- locked <0x9a757fb8> (a org.jboss.web.tomcat.service.WebCtxLoader$ENCLoader)
> 	at $Proxy156.getWarTestObject(Unknown Source)
> 	at org.jboss.ejb3.test.servlet.servlets.EJBServlet.processRequest(EJBServlet.java:95)
> 	at org.jboss.ejb3.test.servlet.servlets.EJBServlet.doGet(EJBServlet.java:146)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 23:11:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 9 Jul 2009 23:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCL-109) Infinite loop when a
 legit LinkageError occurs
In-Reply-To: <157425770.1247195069114.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <439203951.1247195489718.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBCL-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene resolved JBCL-109.
----------------------------------

    Resolution: Done
      Assignee: Jason T. Greene


> Infinite loop when a legit LinkageError occurs
> ----------------------------------------------
>
>                 Key: JBCL-109
>                 URL: https://jira.jboss.org/jira/browse/JBCL-109
>             Project: JBoss ClassLoader
>          Issue Type: Bug
>          Components: ClassLoader
>            Reporter: Jason T. Greene
>            Assignee: Jason T. Greene
>            Priority: Blocker
>             Fix For: JBossCL.2.0.7.GA
>
>
> To fix an old JVM issue, linkage errors are treated like a ClassCircularityException. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-6327), an infinite loop results. 
> synchronized int incrementNumCCE()
>  {
>      return numCCE;;
>   }
> This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP

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

        


From jira-events at lists.jboss.org  Thu Jul  9 23:13:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 9 Jul 2009 23:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7091) Incorrect handling
 of timestamps in clustered session
Message-ID: <2099065379.1247195609545.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Incorrect handling of timestamps in clustered session
-----------------------------------------------------

                 Key: JBAS-7091
                 URL: https://jira.jboss.org/jira/browse/JBAS-7091
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering, Web (Tomcat) service
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-5.2.0.Beta1


ClusteredSession has an "outdatedTime" field that records the timestamp when a session gets a callback notifying of a modification on another node.  If the session state later gets updated from the distributed cache, the clearOutdated() method ends up setting the session timestamp to that "outdatedTime" rather than the correct timestamp that's stored in the distributed cache. That's wrong.

Not a big deal, as the difference between the outdatedTime and the correct timestamp is probably just a few ms (time it takes to replicate the session). But still, it's wrong.

In any case the handling of "outdatedTime" is more complex than need and related "outdatedVersion" field can be removed altogether.  There's a bit of cruft here from the old days when correct timestamps weren't readily available from the cache.

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

        


From jira-events at lists.jboss.org  Thu Jul  9 23:18:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 9 Jul 2009 23:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCL-109) Infinite loop when a
 legit LinkageError occurs
In-Reply-To: <157425770.1247195069114.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1462567792.1247195909125.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBCL-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene updated JBCL-109:
---------------------------------

    Description: 
To fix an old JVM issue, linkage errors are treated like a ClassCircularityError. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-6327), an infinite loop results. 

synchronized int incrementNumCCE()
 {
     return numCCE;;
  }

This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP


  was:
To fix an old JVM issue, linkage errors are treated like a ClassCircularityException. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-6327), an infinite loop results. 

synchronized int incrementNumCCE()
 {
     return numCCE;;
  }

This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP




> Infinite loop when a legit LinkageError occurs
> ----------------------------------------------
>
>                 Key: JBCL-109
>                 URL: https://jira.jboss.org/jira/browse/JBCL-109
>             Project: JBoss ClassLoader
>          Issue Type: Bug
>          Components: ClassLoader
>            Reporter: Jason T. Greene
>            Assignee: Jason T. Greene
>            Priority: Blocker
>             Fix For: JBossCL.2.0.7.GA
>
>
> To fix an old JVM issue, linkage errors are treated like a ClassCircularityError. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-6327), an infinite loop results. 
> synchronized int incrementNumCCE()
>  {
>      return numCCE;;
>   }
> This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP

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

        


From jira-events at lists.jboss.org  Thu Jul  9 23:34:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 23:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1449054916.1247196869166.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475689#action_12475689 ] 

Howard Gao commented on JBMESSAGING-1681:
-----------------------------------------

Thanks!


> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

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

        


From jira-events at lists.jboss.org  Fri Jul 10 00:18:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 10 Jul 2009 00:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6327) Servlet hangs in
	classloader
In-Reply-To: <11803824.1229509077422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <409898025.1247199509429.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene resolved JBAS-6327.
-----------------------------------

    Resolution: Done


Fixed in 5.x branch

> Servlet hangs in classloader
> ----------------------------
>
>                 Key: JBAS-6327
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6327
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Testsuite ejb3/servlet
>            Reporter: Carlo de Wolf
>            Assignee: Jason T. Greene
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> "http-localhost%2F127.0.0.1-8080-1" daemon prio=1 tid=0x10ae3118 nid=0x6b36 runnable [0x7897c000..0x7897df20]
> 	at java.lang.ClassLoader.defineClass1(Native Method)
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:62)
> 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:509)
> 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:469)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:467)
> 	- locked <0x9a2ff1a8> (a org.jboss.classloader.spi.base.BaseClassLoader)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:444)
> 	at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
> 	at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
> 	at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
> 	at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:254)
> 	at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:148)
> 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:256)
> 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1099)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:735)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:378)
> 	- locked <0x9a2ff1a8> (a org.jboss.classloader.spi.base.BaseClassLoader)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
> 	- locked <0x9a757fb8> (a org.jboss.web.tomcat.service.WebCtxLoader$ENCLoader)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> 	- locked <0x9a757fb8> (a org.jboss.web.tomcat.service.WebCtxLoader$ENCLoader)
> 	at $Proxy156.getWarTestObject(Unknown Source)
> 	at org.jboss.ejb3.test.servlet.servlets.EJBServlet.processRequest(EJBServlet.java:95)
> 	at org.jboss.ejb3.test.servlet.servlets.EJBServlet.doGet(EJBServlet.java:146)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 01:21:41 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 10 Jul 2009 01:21:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-99) Create extensible AS
 Server implementation base
Message-ID: <1375381167.1247203301607.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Create extensible AS Server implementation base
-----------------------------------------------

                 Key: JBBOOT-99
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-99
             Project: JBoss Bootstrap
          Issue Type: Task
          Components: impl-as
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 2.0.0-beta-1 


JBossASEmbeddedServerImpl in the EMB project currently extends from JBossASServerImpl, which provides no generics to allow for covarient return.  As a result, the method chaining functions come back as JBossASServer instead of JBossASEmbeddedServer.  

Make an extensible AS server implementation which keeps the generics chain alive.

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

        


From jira-events at lists.jboss.org  Fri Jul 10 02:47:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 10 Jul 2009 02:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <83268276.1247208449203.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475694#action_12475694 ] 

Tim Fox commented on JBMESSAGING-1681:
--------------------------------------

Konstantin-

The ejb tutorial is not written or managed by the JBoss Messaging team, it's handled by the EJB3 team.

If you think it is wrong, then you can raise an issue on the EJB forum and hopefully they will correct it.

> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

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

        


From jira-events at lists.jboss.org  Fri Jul 10 04:26:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 10 Jul 2009 04:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <865530579.1247214389232.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475703#action_12475703 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

To keep the time longer, the node id has to shrink to give up more bits to time. Also we need to increase the granularity of the time bits. So I suggest the ID structure:

1) 10 bits node id (that allow node id to range from 0 to 1023).

2) 39 bits time from System.currentTimeMillis(). 

To make the time of repetition longer than 100 years using only 39 bits, we need to extract it from 4th bit to 42nd bit of the system time. So the time of repetition can be calculated as such

(2^39 - 1)/125/60/60/24/365.25   ====> about 139.36 years.

3) 15 bits counter. (range from 0 to 32767)

So the overall structure of a 64-bit ID is:

[10-bit node id][39-bit time][15-bit counter]













> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Fri Jul 10 04:28:42 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 10 Jul 2009 04:28:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <862976998.1247214522302.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475704#action_12475704 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

The TimeAndCounterIDGenerator in JBM 2.0 is not suitable for 1.4 because it doesn't use node id. We need the node id to guarantee the uniqueness across the cluster (as we use shared DB).



> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Fri Jul 10 04:39:41 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 10 Jul 2009 04:39:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1186648017.1247215181579.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475707#action_12475707 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

Hi Tim,

Can you give some comments on my latest suggestion so that I can move on? Thanks.

Howard

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Fri Jul 10 04:45:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 10 Jul 2009 04:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <153071870.1247215529347.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475708#action_12475708 ] 

Tim Fox commented on JBMESSAGING-1682:
--------------------------------------

Why don't use adapt the JBM 2.0 method to use the node id too?

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Fri Jul 10 04:48:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 04:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1857) Track the
 upgrades during EJB3 plugin 1.0.10 release
In-Reply-To: <11399327.1246000976433.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1461216001.1247215709133.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1857.
------------------------------------

                  Resolution: Done
    Component Fix Version(s): jboss-ejb3-plugin:1.0.10


> Track the upgrades during EJB3 plugin 1.0.10 release
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1857
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1857
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: plugin
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> This issue is to track any updates to version dependencies during the EJB3 1.0.10 plugin release.

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

        


From jira-events at lists.jboss.org  Fri Jul 10 04:50:40 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 04:50:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1858) NPE if in
 resource-env-ref no injection target is specified
In-Reply-To: <15528450.1246042016731.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1415996817.1247215840375.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1858.
------------------------------------

    Fix Version/s: 1.1.9
       Resolution: Done


> NPE if in resource-env-ref no injection target is specified
> -----------------------------------------------------------
>
>                 Key: EJBTHREE-1858
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1858
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.7
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>             Fix For: 1.1.9
>
>         Attachments: ResourceEnvRefNPE.jar
>
>
> If an ENC entry for java:/comp/EJBContext is declared and NO injection target is specified, this results in a NPE.
> 			<resource-env-ref>
> 				<resource-env-ref-name>EnvNameOfSessionContext</resource-env-ref-name>
>  				<resource-env-ref-type>javax.ejb.SessionContext</resource-env-ref-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 			</resource-env-ref>
> The exception is:
> ...
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.InjectionUtil.createInjectors(InjectionUtil.java:105)
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceEnvRefs(ResourceHandler.java:227)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:343)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:597)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:434)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:543)
> 	... 69 more
> Looking at the code in ResourceHandler.loadXmlResourceEnvRefs, this is the only place where the check "if(envRef.getInjectionTargets() != null)" is missing ;-).
> I will attach a sample.

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

        


From jira-events at lists.jboss.org  Fri Jul 10 04:59:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 04:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1854) Configure EJB3
 MC beans to avoid AOPDependencyBuilder
In-Reply-To: <16175879.1245767758566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1329489515.1247216369232.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1854:
-----------------------------------

    Component/s: proxy-impl
                     (was: deployers)


> Configure EJB3 MC beans to avoid AOPDependencyBuilder
> -----------------------------------------------------
>
>                 Key: EJBTHREE-1854
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1854
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: core, proxy-impl
>    Affects Versions: 1.1.7
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> This task is to keep track of the change(s) required for all EJB3 MC bean (programatic and xml based) to ensure that the AOPDependencyBuilder does not come into picture during deployment. Avoiding AOPDependencyBuilder has shown good performance improvements.
> There isn't a final decision yet on how to do this although MC provides @DisableAOP annotation to achieve this. The MC support for this is currently available in AS 5_x branch and needs to be ported to AS trunk before EJB3 can think of using this. Once there's a decision on what's the best approach to accomplish this, we can do the changes in EJB3.

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

        


From jira-events at lists.jboss.org  Fri Jul 10 05:03:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 10 Jul 2009 05:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <606259378.1247216609363.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475710#action_12475710 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

--- Why don't use adapt the JBM 2.0 method to use the node id too? 

If you mean TimeAndCounterIDGenerator, I don't think it would make much difference. This class uses [44 bits time] + [20 bits counter]. If we add the node id bits in, that will be the same as the existing one.

It's strange I can't find where this class is used in JBM 2.0 other than in tests. but I can't find any other class that do the job.

Howard


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Fri Jul 10 05:03:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 05:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1854) Configure EJB3
 MC beans to avoid AOPDependencyBuilder
In-Reply-To: <16175879.1245767758566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2029387919.1247216609260.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1854.
------------------------------------

               Fix Version/s: 1.1.9
                  Resolution: Done
    Component Fix Version(s): jboss-ejb3-core:1.1.9 jboss-ejb3-proxy-impl:1.0.3


The EJB3 containers and the proxy factories which are registed as MC beans, now use @DisableAOP. Furthermore, the EJB3 MC bean configuration xmls have also been updated to use this annotation.


> Configure EJB3 MC beans to avoid AOPDependencyBuilder
> -----------------------------------------------------
>
>                 Key: EJBTHREE-1854
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1854
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: core, proxy-impl
>    Affects Versions: 1.1.7
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 1.1.9
>
>
> This task is to keep track of the change(s) required for all EJB3 MC bean (programatic and xml based) to ensure that the AOPDependencyBuilder does not come into picture during deployment. Avoiding AOPDependencyBuilder has shown good performance improvements.
> There isn't a final decision yet on how to do this although MC provides @DisableAOP annotation to achieve this. The MC support for this is currently available in AS 5_x branch and needs to be ported to AS trunk before EJB3 can think of using this. Once there's a decision on what's the best approach to accomplish this, we can do the changes in EJB3.

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

        


From jira-events at lists.jboss.org  Fri Jul 10 05:05:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 10 Jul 2009 05:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1184395753.1247216729288.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475711#action_12475711 ] 

Tim Fox commented on JBMESSAGING-1682:
--------------------------------------

You're looking at the wrong class, the correct one is JournalStorageManagerImpl.BatchingIDGenerator

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Fri Jul 10 05:09:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 05:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1861) Upgrade
 microcontainer to 2.0.8.GA
In-Reply-To: <2037967472.1246535944178.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1826127143.1247216969135.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1861:
-----------------------------------

    Component/s: build


> Upgrade microcontainer to 2.0.8.GA
> ----------------------------------
>
>                 Key: EJBTHREE-1861
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1861
>             Project: EJB 3.0
>          Issue Type: Thirdparty Change
>          Components: build
>    Affects Versions: 1.1.8
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> In order to be able to use the @DisableAOP feature in MC, we need to upgrade to this latest version of MC. 

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

        


From jira-events at lists.jboss.org  Fri Jul 10 05:26:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 05:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1861) Upgrade
 microcontainer to 2.0.8.GA
In-Reply-To: <2037967472.1246535944178.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1448282406.1247217989111.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1861.
------------------------------------

               Fix Version/s: 1.1.9
                  Resolution: Done
    Component Fix Version(s): jboss-ejb3-build:1.0.4


> Upgrade microcontainer to 2.0.8.GA
> ----------------------------------
>
>                 Key: EJBTHREE-1861
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1861
>             Project: EJB 3.0
>          Issue Type: Thirdparty Change
>          Components: build
>    Affects Versions: 1.1.8
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 1.1.9
>
>
> In order to be able to use the @DisableAOP feature in MC, we need to upgrade to this latest version of MC. 

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

        


From jira-events at lists.jboss.org  Fri Jul 10 05:28:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 05:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1858) NPE if in
 resource-env-ref no injection target is specified
In-Reply-To: <15528450.1246042016731.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1811300737.1247218109324.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1858:
-----------------------------------

    Component/s: core


> NPE if in resource-env-ref no injection target is specified
> -----------------------------------------------------------
>
>                 Key: EJBTHREE-1858
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1858
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.7
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>             Fix For: 1.1.9
>
>         Attachments: ResourceEnvRefNPE.jar
>
>
> If an ENC entry for java:/comp/EJBContext is declared and NO injection target is specified, this results in a NPE.
> 			<resource-env-ref>
> 				<resource-env-ref-name>EnvNameOfSessionContext</resource-env-ref-name>
>  				<resource-env-ref-type>javax.ejb.SessionContext</resource-env-ref-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 			</resource-env-ref>
> The exception is:
> ...
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.InjectionUtil.createInjectors(InjectionUtil.java:105)
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceEnvRefs(ResourceHandler.java:227)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:343)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:597)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:434)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:543)
> 	... 69 more
> Looking at the code in ResourceHandler.loadXmlResourceEnvRefs, this is the only place where the check "if(envRef.getInjectionTargets() != null)" is missing ;-).
> I will attach a sample.

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

        


From jira-events at lists.jboss.org  Fri Jul 10 05:34:42 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 10 Jul 2009 05:34:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <332247889.1247218482838.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475712#action_12475712 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

Thanks Tim, I had a look at it and I think the idea is to drop the time bits and use check points.

So the idea would be:

[10 bits node-id][54 bits counter]

This eliminates the time issue. But we need:

create a table in the DB, store checkpoints for each node.

It looks like a simple solution, I'll try this way. 

Comments?

Howard


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Fri Jul 10 05:42:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 05:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1867) Track the
 upgrades during EJB3 plugin 1.0.11 release
Message-ID: <260824002.1247218949130.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Track the upgrades during EJB3 plugin 1.0.11 release
----------------------------------------------------

                 Key: EJBTHREE-1867
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1867
             Project: EJB 3.0
          Issue Type: Task
          Components: plugin
            Reporter: jaikiran pai
            Assignee: jaikiran pai


This JIRA will track the dependency upgrades during the release of EJB3 plugin 1.0.11

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

        


From jira-events at lists.jboss.org  Fri Jul 10 06:21:29 2009
From: jira-events at lists.jboss.org (Christian Spurk (JIRA))
Date: Fri, 10 Jul 2009 06:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2203)
 NullPointerException When
 Using Conditional Element "or" in LHS Together with a Return Value
 Restriction
In-Reply-To: <1905551867.1247221071455.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1188629659.1247221289321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Spurk updated JBRULES-2203:
-------------------------------------

    Description: 
When using the conditional element "or" on the left hand side of a rule together with a return value restriction somewhere in the same rule, I get the following exception:

{quote}
Exception in thread "main" java.lang.NullPointerException
	at org.drools.rule.ReturnValueRestriction.equals(ReturnValueRestriction.java:304)
	at org.drools.rule.ReturnValueConstraint.equals(ReturnValueConstraint.java:121)
	at org.drools.reteoo.AlphaNode.equals(AlphaNode.java:218)
	at org.drools.reteoo.SingleObjectSinkAdapter.getMatchingNode(SingleObjectSinkAdapter.java:48)
	at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:130)
	at org.drools.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:295)
	at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:117)
	at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:70)
	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:126)
	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:73)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:153)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:126)
	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:362)
	at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:618)
	at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:500)
	at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:379)
	at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:121)
	at com.sample.DroolsTest.readKnowledgeBase(DroolsTest.java:48)
	at com.sample.DroolsTest.main(DroolsTest.java:26)
{quote}

Here is a simple test case which can be used to reproduce the issue:

{code}
/* JAVA FILE TO LOAD THE RULE */
package com.sample;

import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderError;
import org.drools.builder.KnowledgeBuilderErrors;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.builder.ResourceType;
import org.drools.io.ResourceFactory;
import org.drools.runtime.StatefulKnowledgeSession;

public class DroolsTest {

	private int arg;

	public int getArg() {
		return this.arg;
	}

	public void setArg(int arg) {
		this.arg = arg;
	}

	public static final void main(String[] args) throws Exception {
		KnowledgeBase kbase = readKnowledgeBase();
		StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

		DroolsTest test = new DroolsTest();
		test.setArg(2);
		ksession.insert(test);

		ksession.fireAllRules();
	}

	/* taken verbatim from the Hello World sample */
	private static KnowledgeBase readKnowledgeBase() throws Exception {
		KnowledgeBuilder kbuilder = KnowledgeBuilderFactory
				.newKnowledgeBuilder();
		kbuilder.add(ResourceFactory.newClassPathResource("Sample.drl"),
				ResourceType.DRL);
		KnowledgeBuilderErrors errors = kbuilder.getErrors();
		if (errors.size() > 0) {
			for (KnowledgeBuilderError error : errors) {
				System.err.println(error);
			}
			throw new IllegalArgumentException("Could not parse knowledge.");
		}
		KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
		kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
		return kbase;
	}

}
{code}


{code}
/* PROBLEMATIC RULE FILE */
package com.sample
 
import com.sample.DroolsTest;

rule "test"
	when
		DroolsTest( arg == (1 + 1) );
		// REMOVE THE COMMENTED PARTS BELOW TO GET THE EXCEPTION:
		//(or	eval(true);
			eval(true);
		//)
	then
		System.out.println( "it works!" );
end
{code}


When the above Java file is compiled and run in combination with the given rule file, everything works fine. However, if the marked parts of the rule are uncommented, then you get the exception.

PS: It seems that the issue has been existing in previous Drools versions already, see https://jira.jboss.org/jira/browse/JBSEAM-3064 for example ("Drools 4.0.7 don't like 'action == (DocumentType.USER.extendedName())' and multiple OR's - weird!").


  was:
When using the conditional element "or" on the left hand side of a rule together with a return value restriction somewhere in the same rule, I get the following exception:

Exception in thread "main" java.lang.NullPointerException
	at org.drools.rule.ReturnValueRestriction.equals(ReturnValueRestriction.java:304)
	at org.drools.rule.ReturnValueConstraint.equals(ReturnValueConstraint.java:121)
	at org.drools.reteoo.AlphaNode.equals(AlphaNode.java:218)
	at org.drools.reteoo.SingleObjectSinkAdapter.getMatchingNode(SingleObjectSinkAdapter.java:48)
	at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:130)
	at org.drools.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:295)
	at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:117)
	at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:70)
	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:126)
	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:73)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:153)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:126)
	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:362)
	at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:618)
	at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:500)
	at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:379)
	at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:121)
	at com.sample.DroolsTest.readKnowledgeBase(DroolsTest.java:48)
	at com.sample.DroolsTest.main(DroolsTest.java:26)

Here is a simple test case which can be used to reproduce the issue:

/* JAVA FILE TO LOAD THE RULE */
package com.sample;

import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderError;
import org.drools.builder.KnowledgeBuilderErrors;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.builder.ResourceType;
import org.drools.io.ResourceFactory;
import org.drools.runtime.StatefulKnowledgeSession;

public class DroolsTest {

	private int arg;

	public int getArg() {
		return this.arg;
	}

	public void setArg(int arg) {
		this.arg = arg;
	}

	public static final void main(String[] args) throws Exception {
		KnowledgeBase kbase = readKnowledgeBase();
		StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

		DroolsTest test = new DroolsTest();
		test.setArg(2);
		ksession.insert(test);

		ksession.fireAllRules();
	}

	/* taken verbatim from the Hello World sample */
	private static KnowledgeBase readKnowledgeBase() throws Exception {
		KnowledgeBuilder kbuilder = KnowledgeBuilderFactory
				.newKnowledgeBuilder();
		kbuilder.add(ResourceFactory.newClassPathResource("Sample.drl"),
				ResourceType.DRL);
		KnowledgeBuilderErrors errors = kbuilder.getErrors();
		if (errors.size() > 0) {
			for (KnowledgeBuilderError error : errors) {
				System.err.println(error);
			}
			throw new IllegalArgumentException("Could not parse knowledge.");
		}
		KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
		kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
		return kbase;
	}

}


/* PROBLEMATIC RULE FILE */
package com.sample
 
import com.sample.DroolsTest;

rule "test"
	when
		DroolsTest( arg == (1 + 1) );
		// REMOVE THE COMMENTED PARTS BELOW TO GET THE EXCEPTION:
		//(or	eval(true);
			eval(true);
		//)
	then
		System.out.println( "it works!" );
end


When the above Java file is compiled and run in combination with the given rule file, everything works fine. However, if the marked parts of the rule are uncommented, then you get the exception.

PS: It seems that the issue has been existing in previous Drools versions already, see https://jira.jboss.org/jira/browse/JBSEAM-3064 for example ("Drools 4.0.7 don't like 'action == (DocumentType.USER.extendedName())' and multiple OR's - weird!").




> NullPointerException When Using Conditional Element "or" in LHS Together with a Return Value Restriction
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2203
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2203
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (expert)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Drools 5.0.1 used in an Eclipse Drools project under Windows XP with Java 1.6
>            Reporter: Christian Spurk
>            Assignee: Mark Proctor
>
> When using the conditional element "or" on the left hand side of a rule together with a return value restriction somewhere in the same rule, I get the following exception:
> {quote}
> Exception in thread "main" java.lang.NullPointerException
> 	at org.drools.rule.ReturnValueRestriction.equals(ReturnValueRestriction.java:304)
> 	at org.drools.rule.ReturnValueConstraint.equals(ReturnValueConstraint.java:121)
> 	at org.drools.reteoo.AlphaNode.equals(AlphaNode.java:218)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.getMatchingNode(SingleObjectSinkAdapter.java:48)
> 	at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:130)
> 	at org.drools.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:295)
> 	at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:117)
> 	at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:70)
> 	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:126)
> 	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:73)
> 	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:153)
> 	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:126)
> 	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
> 	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:362)
> 	at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:618)
> 	at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:500)
> 	at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:379)
> 	at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:121)
> 	at com.sample.DroolsTest.readKnowledgeBase(DroolsTest.java:48)
> 	at com.sample.DroolsTest.main(DroolsTest.java:26)
> {quote}
> Here is a simple test case which can be used to reproduce the issue:
> {code}
> /* JAVA FILE TO LOAD THE RULE */
> package com.sample;
> import org.drools.KnowledgeBase;
> import org.drools.KnowledgeBaseFactory;
> import org.drools.builder.KnowledgeBuilder;
> import org.drools.builder.KnowledgeBuilderError;
> import org.drools.builder.KnowledgeBuilderErrors;
> import org.drools.builder.KnowledgeBuilderFactory;
> import org.drools.builder.ResourceType;
> import org.drools.io.ResourceFactory;
> import org.drools.runtime.StatefulKnowledgeSession;
> public class DroolsTest {
> 	private int arg;
> 	public int getArg() {
> 		return this.arg;
> 	}
> 	public void setArg(int arg) {
> 		this.arg = arg;
> 	}
> 	public static final void main(String[] args) throws Exception {
> 		KnowledgeBase kbase = readKnowledgeBase();
> 		StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
> 		DroolsTest test = new DroolsTest();
> 		test.setArg(2);
> 		ksession.insert(test);
> 		ksession.fireAllRules();
> 	}
> 	/* taken verbatim from the Hello World sample */
> 	private static KnowledgeBase readKnowledgeBase() throws Exception {
> 		KnowledgeBuilder kbuilder = KnowledgeBuilderFactory
> 				.newKnowledgeBuilder();
> 		kbuilder.add(ResourceFactory.newClassPathResource("Sample.drl"),
> 				ResourceType.DRL);
> 		KnowledgeBuilderErrors errors = kbuilder.getErrors();
> 		if (errors.size() > 0) {
> 			for (KnowledgeBuilderError error : errors) {
> 				System.err.println(error);
> 			}
> 			throw new IllegalArgumentException("Could not parse knowledge.");
> 		}
> 		KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
> 		kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
> 		return kbase;
> 	}
> }
> {code}
> {code}
> /* PROBLEMATIC RULE FILE */
> package com.sample
>  
> import com.sample.DroolsTest;
> rule "test"
> 	when
> 		DroolsTest( arg == (1 + 1) );
> 		// REMOVE THE COMMENTED PARTS BELOW TO GET THE EXCEPTION:
> 		//(or	eval(true);
> 			eval(true);
> 		//)
> 	then
> 		System.out.println( "it works!" );
> end
> {code}
> When the above Java file is compiled and run in combination with the given rule file, everything works fine. However, if the marked parts of the rule are uncommented, then you get the exception.
> PS: It seems that the issue has been existing in previous Drools versions already, see https://jira.jboss.org/jira/browse/JBSEAM-3064 for example ("Drools 4.0.7 don't like 'action == (DocumentType.USER.extendedName())' and multiple OR's - weird!").

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

        


From jira-events at lists.jboss.org  Fri Jul 10 06:23:29 2009
From: jira-events at lists.jboss.org (Christian Spurk (JIRA))
Date: Fri, 10 Jul 2009 06:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2203)
 NullPointerException When
 Using Conditional Element "or" in LHS Together with a Return Value
 Restriction
In-Reply-To: <1905551867.1247221071455.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <645657579.1247221409336.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Spurk updated JBRULES-2203:
-------------------------------------

    Description: 
When using the conditional element "or" on the left hand side of a rule together with a return value restriction somewhere in the same rule, I get the following exception:


Exception in thread "main" java.lang.NullPointerException
	at org.drools.rule.ReturnValueRestriction.equals(ReturnValueRestriction.java:304)
	at org.drools.rule.ReturnValueConstraint.equals(ReturnValueConstraint.java:121)
	at org.drools.reteoo.AlphaNode.equals(AlphaNode.java:218)
	at org.drools.reteoo.SingleObjectSinkAdapter.getMatchingNode(SingleObjectSinkAdapter.java:48)
	at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:130)
	at org.drools.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:295)
	at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:117)
	at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:70)
	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:126)
	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:73)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:153)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:126)
	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:362)
	at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:618)
	at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:500)
	at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:379)
	at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:121)
	at com.sample.DroolsTest.readKnowledgeBase(DroolsTest.java:48)
	at com.sample.DroolsTest.main(DroolsTest.java:26)


Here is a simple test case which can be used to reproduce the issue:


/* JAVA FILE TO LOAD THE RULE */
package com.sample;

import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderError;
import org.drools.builder.KnowledgeBuilderErrors;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.builder.ResourceType;
import org.drools.io.ResourceFactory;
import org.drools.runtime.StatefulKnowledgeSession;

public class DroolsTest {

	private int arg;

	public int getArg() {
		return this.arg;
	}

	public void setArg(int arg) {
		this.arg = arg;
	}

	public static final void main(String[] args) throws Exception {
		KnowledgeBase kbase = readKnowledgeBase();
		StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

		DroolsTest test = new DroolsTest();
		test.setArg(2);
		ksession.insert(test);

		ksession.fireAllRules();
	}

	/* taken verbatim from the Hello World sample */
	private static KnowledgeBase readKnowledgeBase() throws Exception {
		KnowledgeBuilder kbuilder = KnowledgeBuilderFactory
				.newKnowledgeBuilder();
		kbuilder.add(ResourceFactory.newClassPathResource("Sample.drl"),
				ResourceType.DRL);
		KnowledgeBuilderErrors errors = kbuilder.getErrors();
		if (errors.size() > 0) {
			for (KnowledgeBuilderError error : errors) {
				System.err.println(error);
			}
			throw new IllegalArgumentException("Could not parse knowledge.");
		}
		KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
		kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
		return kbase;
	}

}




/* PROBLEMATIC RULE FILE */
package com.sample
 
import com.sample.DroolsTest;

rule "test"
	when
		DroolsTest( arg == (1 + 1) );
		// REMOVE THE COMMENTED PARTS BELOW TO GET THE EXCEPTION:
		//(or	eval(true);
			eval(true);
		//)
	then
		System.out.println( "it works!" );
end


When the above Java file is compiled and run in combination with the given rule file, everything works fine. However, if the marked parts of the rule are uncommented, then you get the exception.

PS: It seems that the issue has been existing in previous Drools versions already, see https://jira.jboss.org/jira/browse/JBSEAM-3064 for example ("Drools 4.0.7 don't like 'action == (DocumentType.USER.extendedName())' and multiple OR's - weird!").


  was:
When using the conditional element "or" on the left hand side of a rule together with a return value restriction somewhere in the same rule, I get the following exception:

{quote}
Exception in thread "main" java.lang.NullPointerException
	at org.drools.rule.ReturnValueRestriction.equals(ReturnValueRestriction.java:304)
	at org.drools.rule.ReturnValueConstraint.equals(ReturnValueConstraint.java:121)
	at org.drools.reteoo.AlphaNode.equals(AlphaNode.java:218)
	at org.drools.reteoo.SingleObjectSinkAdapter.getMatchingNode(SingleObjectSinkAdapter.java:48)
	at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:130)
	at org.drools.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:295)
	at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:117)
	at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:70)
	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:126)
	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:73)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:153)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:126)
	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:362)
	at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:618)
	at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:500)
	at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:379)
	at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:121)
	at com.sample.DroolsTest.readKnowledgeBase(DroolsTest.java:48)
	at com.sample.DroolsTest.main(DroolsTest.java:26)
{quote}

Here is a simple test case which can be used to reproduce the issue:

{code}
/* JAVA FILE TO LOAD THE RULE */
package com.sample;

import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderError;
import org.drools.builder.KnowledgeBuilderErrors;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.builder.ResourceType;
import org.drools.io.ResourceFactory;
import org.drools.runtime.StatefulKnowledgeSession;

public class DroolsTest {

	private int arg;

	public int getArg() {
		return this.arg;
	}

	public void setArg(int arg) {
		this.arg = arg;
	}

	public static final void main(String[] args) throws Exception {
		KnowledgeBase kbase = readKnowledgeBase();
		StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

		DroolsTest test = new DroolsTest();
		test.setArg(2);
		ksession.insert(test);

		ksession.fireAllRules();
	}

	/* taken verbatim from the Hello World sample */
	private static KnowledgeBase readKnowledgeBase() throws Exception {
		KnowledgeBuilder kbuilder = KnowledgeBuilderFactory
				.newKnowledgeBuilder();
		kbuilder.add(ResourceFactory.newClassPathResource("Sample.drl"),
				ResourceType.DRL);
		KnowledgeBuilderErrors errors = kbuilder.getErrors();
		if (errors.size() > 0) {
			for (KnowledgeBuilderError error : errors) {
				System.err.println(error);
			}
			throw new IllegalArgumentException("Could not parse knowledge.");
		}
		KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
		kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
		return kbase;
	}

}
{code}


{code}
/* PROBLEMATIC RULE FILE */
package com.sample
 
import com.sample.DroolsTest;

rule "test"
	when
		DroolsTest( arg == (1 + 1) );
		// REMOVE THE COMMENTED PARTS BELOW TO GET THE EXCEPTION:
		//(or	eval(true);
			eval(true);
		//)
	then
		System.out.println( "it works!" );
end
{code}


When the above Java file is compiled and run in combination with the given rule file, everything works fine. However, if the marked parts of the rule are uncommented, then you get the exception.

PS: It seems that the issue has been existing in previous Drools versions already, see https://jira.jboss.org/jira/browse/JBSEAM-3064 for example ("Drools 4.0.7 don't like 'action == (DocumentType.USER.extendedName())' and multiple OR's - weird!").




> NullPointerException When Using Conditional Element "or" in LHS Together with a Return Value Restriction
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2203
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2203
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (expert)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Drools 5.0.1 used in an Eclipse Drools project under Windows XP with Java 1.6
>            Reporter: Christian Spurk
>            Assignee: Mark Proctor
>
> When using the conditional element "or" on the left hand side of a rule together with a return value restriction somewhere in the same rule, I get the following exception:
> Exception in thread "main" java.lang.NullPointerException
> 	at org.drools.rule.ReturnValueRestriction.equals(ReturnValueRestriction.java:304)
> 	at org.drools.rule.ReturnValueConstraint.equals(ReturnValueConstraint.java:121)
> 	at org.drools.reteoo.AlphaNode.equals(AlphaNode.java:218)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.getMatchingNode(SingleObjectSinkAdapter.java:48)
> 	at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:130)
> 	at org.drools.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:295)
> 	at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:117)
> 	at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:70)
> 	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:126)
> 	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:73)
> 	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:153)
> 	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:126)
> 	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
> 	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:362)
> 	at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:618)
> 	at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:500)
> 	at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:379)
> 	at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:121)
> 	at com.sample.DroolsTest.readKnowledgeBase(DroolsTest.java:48)
> 	at com.sample.DroolsTest.main(DroolsTest.java:26)
> Here is a simple test case which can be used to reproduce the issue:
> /* JAVA FILE TO LOAD THE RULE */
> package com.sample;
> import org.drools.KnowledgeBase;
> import org.drools.KnowledgeBaseFactory;
> import org.drools.builder.KnowledgeBuilder;
> import org.drools.builder.KnowledgeBuilderError;
> import org.drools.builder.KnowledgeBuilderErrors;
> import org.drools.builder.KnowledgeBuilderFactory;
> import org.drools.builder.ResourceType;
> import org.drools.io.ResourceFactory;
> import org.drools.runtime.StatefulKnowledgeSession;
> public class DroolsTest {
> 	private int arg;
> 	public int getArg() {
> 		return this.arg;
> 	}
> 	public void setArg(int arg) {
> 		this.arg = arg;
> 	}
> 	public static final void main(String[] args) throws Exception {
> 		KnowledgeBase kbase = readKnowledgeBase();
> 		StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
> 		DroolsTest test = new DroolsTest();
> 		test.setArg(2);
> 		ksession.insert(test);
> 		ksession.fireAllRules();
> 	}
> 	/* taken verbatim from the Hello World sample */
> 	private static KnowledgeBase readKnowledgeBase() throws Exception {
> 		KnowledgeBuilder kbuilder = KnowledgeBuilderFactory
> 				.newKnowledgeBuilder();
> 		kbuilder.add(ResourceFactory.newClassPathResource("Sample.drl"),
> 				ResourceType.DRL);
> 		KnowledgeBuilderErrors errors = kbuilder.getErrors();
> 		if (errors.size() > 0) {
> 			for (KnowledgeBuilderError error : errors) {
> 				System.err.println(error);
> 			}
> 			throw new IllegalArgumentException("Could not parse knowledge.");
> 		}
> 		KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
> 		kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
> 		return kbase;
> 	}
> }
> /* PROBLEMATIC RULE FILE */
> package com.sample
>  
> import com.sample.DroolsTest;
> rule "test"
> 	when
> 		DroolsTest( arg == (1 + 1) );
> 		// REMOVE THE COMMENTED PARTS BELOW TO GET THE EXCEPTION:
> 		//(or	eval(true);
> 			eval(true);
> 		//)
> 	then
> 		System.out.println( "it works!" );
> end
> When the above Java file is compiled and run in combination with the given rule file, everything works fine. However, if the marked parts of the rule are uncommented, then you get the exception.
> PS: It seems that the issue has been existing in previous Drools versions already, see https://jira.jboss.org/jira/browse/JBSEAM-3064 for example ("Drools 4.0.7 don't like 'action == (DocumentType.USER.extendedName())' and multiple OR's - weird!").

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

        


From jira-events at lists.jboss.org  Fri Jul 10 07:45:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 10 Jul 2009 07:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <678469498.1247226329256.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475718#action_12475718 ] 

Tim Fox commented on JBMESSAGING-1682:
--------------------------------------

Bear in mind you may not be able to make database changes on a CP release

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Fri Jul 10 07:51:29 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 10 Jul 2009 07:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <781028316.1247226689638.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475719#action_12475719 ] 

Scott Marlow commented on JBAS-6185:
------------------------------------

I verified that both ideas from Mike Van Noord do resolve the issue (jconsole will work with both jdk 5 + 6).  

> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Scott Marlow
>            Priority: Blocker
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

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

        


From jira-events at lists.jboss.org  Fri Jul 10 08:30:42 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 10 Jul 2009 08:30:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1266948613.1247229042279.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475725#action_12475725 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

yeah, DB change seems not like a good idea. 


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Fri Jul 10 08:45:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 10 Jul 2009 08:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1129931268.1247229929350.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475728#action_12475728 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

I think I'll go back to my previous way, 
[10-bit node id][39-bit time][15-bit counter] 

This reduces the node id range from 65535 to 1023. It's not likely that there exists a single cluster of size larger than 1024 nodes.


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Fri Jul 10 08:52:40 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 10 Jul 2009 08:52:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <835486024.1247230360717.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475729#action_12475729 ] 

Tim Fox commented on JBMESSAGING-1682:
--------------------------------------

If you use 39 bits from the time but only take from the 4th bit, then you will only be able to create a maximum of
2^16/2^4 = 2^12 = 4096 ids per millisecond before overlap

=4096000. hopefully should be enough for JBM 1.x

make sure you change the logic that checks for counter overlap since right now it's assumes 1 millisecond precision

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Fri Jul 10 09:07:29 2009
From: jira-events at lists.jboss.org (anil kumar (JIRA))
Date: Fri, 10 Jul 2009 09:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7093) communitcation from
 scriptlet to jsf managed bean is not working
Message-ID: <404200839.1247231249370.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

communitcation from scriptlet to jsf managed bean is not working
----------------------------------------------------------------

                 Key: JBAS-7093
                 URL: https://jira.jboss.org/jira/browse/JBAS-7093
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JSF
    Affects Versions: JBossAS-5.1.0.GA
         Environment: windows
            Reporter: anil kumar
            Assignee: Stan Silvert



Here is the sample code.
   <%
                    
            for (int i = 1; i < 5; i++) {
                HeaderBean header = new HeaderBean();
                header.setScreenID("" + i);
                application.setAttribute("HeaderBean", header);
               %>                                     
                    
                <h:outputText  value="#{HeaderBean.screenID}"> </h:outputText> 	
                    
 <%}%>        

its always displaying the last value,the out put is "4444" instead of "1234". Is this expected behavior?



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

        


From jira-events at lists.jboss.org  Fri Jul 10 09:09:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 10 Jul 2009 09:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <718533783.1247231369211.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475735#action_12475735 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

yes you are right, about 4 million a second for a single node.

I'll be careful about the logic. Thanks.



> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Fri Jul 10 06:17:51 2009
From: jira-events at lists.jboss.org (Christian Spurk (JIRA))
Date: Fri, 10 Jul 2009 06:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2203)
 NullPointerException When
 Using Conditional Element "or" in LHS Together with a Return Value
 Restriction
Message-ID: <1905551867.1247221071455.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

NullPointerException When Using Conditional Element "or" in LHS Together with a Return Value Restriction
--------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2203
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2203
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler (expert)
    Affects Versions: 5.0.1.FINAL
         Environment: Drools 5.0.1 used in an Eclipse Drools project under Windows XP with Java 1.6
            Reporter: Christian Spurk
            Assignee: Mark Proctor


When using the conditional element "or" on the left hand side of a rule together with a return value restriction somewhere in the same rule, I get the following exception:

Exception in thread "main" java.lang.NullPointerException
	at org.drools.rule.ReturnValueRestriction.equals(ReturnValueRestriction.java:304)
	at org.drools.rule.ReturnValueConstraint.equals(ReturnValueConstraint.java:121)
	at org.drools.reteoo.AlphaNode.equals(AlphaNode.java:218)
	at org.drools.reteoo.SingleObjectSinkAdapter.getMatchingNode(SingleObjectSinkAdapter.java:48)
	at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:130)
	at org.drools.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:295)
	at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:117)
	at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:70)
	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:126)
	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:73)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:153)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:126)
	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:362)
	at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:618)
	at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:500)
	at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:379)
	at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:121)
	at com.sample.DroolsTest.readKnowledgeBase(DroolsTest.java:48)
	at com.sample.DroolsTest.main(DroolsTest.java:26)

Here is a simple test case which can be used to reproduce the issue:

/* JAVA FILE TO LOAD THE RULE */
package com.sample;

import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderError;
import org.drools.builder.KnowledgeBuilderErrors;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.builder.ResourceType;
import org.drools.io.ResourceFactory;
import org.drools.runtime.StatefulKnowledgeSession;

public class DroolsTest {

	private int arg;

	public int getArg() {
		return this.arg;
	}

	public void setArg(int arg) {
		this.arg = arg;
	}

	public static final void main(String[] args) throws Exception {
		KnowledgeBase kbase = readKnowledgeBase();
		StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

		DroolsTest test = new DroolsTest();
		test.setArg(2);
		ksession.insert(test);

		ksession.fireAllRules();
	}

	/* taken verbatim from the Hello World sample */
	private static KnowledgeBase readKnowledgeBase() throws Exception {
		KnowledgeBuilder kbuilder = KnowledgeBuilderFactory
				.newKnowledgeBuilder();
		kbuilder.add(ResourceFactory.newClassPathResource("Sample.drl"),
				ResourceType.DRL);
		KnowledgeBuilderErrors errors = kbuilder.getErrors();
		if (errors.size() > 0) {
			for (KnowledgeBuilderError error : errors) {
				System.err.println(error);
			}
			throw new IllegalArgumentException("Could not parse knowledge.");
		}
		KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
		kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
		return kbase;
	}

}


/* PROBLEMATIC RULE FILE */
package com.sample
 
import com.sample.DroolsTest;

rule "test"
	when
		DroolsTest( arg == (1 + 1) );
		// REMOVE THE COMMENTED PARTS BELOW TO GET THE EXCEPTION:
		//(or	eval(true);
			eval(true);
		//)
	then
		System.out.println( "it works!" );
end


When the above Java file is compiled and run in combination with the given rule file, everything works fine. However, if the marked parts of the rule are uncommented, then you get the exception.

PS: It seems that the issue has been existing in previous Drools versions already, see https://jira.jboss.org/jira/browse/JBSEAM-3064 for example ("Drools 4.0.7 don't like 'action == (DocumentType.USER.extendedName())' and multiple OR's - weird!").


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

        


From jira-events at lists.jboss.org  Fri Jul 10 09:13:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Fri, 10 Jul 2009 09:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7093) communitcation from
 scriptlet to jsf managed bean is not working
In-Reply-To: <404200839.1247231249370.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <70412642.1247231609238.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert resolved JBAS-7093.
--------------------------------

    Resolution: Rejected


Anil,

Jira is for bug reports.  You should ask user questions in the forums.

Stan

> communitcation from scriptlet to jsf managed bean is not working
> ----------------------------------------------------------------
>
>                 Key: JBAS-7093
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7093
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: windows
>            Reporter: anil kumar
>            Assignee: Stan Silvert
>
> Here is the sample code.
>    <%
>                     
>             for (int i = 1; i < 5; i++) {
>                 HeaderBean header = new HeaderBean();
>                 header.setScreenID("" + i);
>                 application.setAttribute("HeaderBean", header);
>                %>                                     
>                     
>                 <h:outputText  value="#{HeaderBean.screenID}"> </h:outputText> 	
>                     
>  <%}%>        
> its always displaying the last value,the out put is "4444" instead of "1234". Is this expected behavior?

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

        


From jira-events at lists.jboss.org  Fri Jul 10 08:30:42 2009
From: jira-events at lists.jboss.org (Michal Rorat (JIRA))
Date: Fri, 10 Jul 2009 08:30:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7092) Server fails to
 deploy war files in ear.
Message-ID: <775540505.1247229042120.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Server fails to deploy war files in ear.
----------------------------------------

                 Key: JBAS-7092
                 URL: https://jira.jboss.org/jira/browse/JBAS-7092
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Deployers
    Affects Versions: JBossAS-4.2.3.GA
         Environment: Windows XP 32 bit
Windows 2003 Server
            Reporter: Michal Rorat
            Assignee: Ales Justin


I have an ear file which contains ejbs and wars. It started to fail when I added sars. The problem is, it doesn't matter what wars I'm deploying, its always the second one and nothing gets deployed after this exception.

aplication.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:application="http://java.sun.com/xml/ns/javaee/application_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd" id="Application_ID" version="5">
  <module>
    <java>OracleQueue.sar</java>
  </module>
  <module>
    <java>SONController.sar</java>
  </module>
  <module>
    <ejb>Admin.jar</ejb>
  </module>
  <module>
    <ejb>Settings.jar</ejb>
  </module>
  <module>
    <ejb>Layer3Msg.jar</ejb>
  </module>
  <module>
    <java>Layer3MsgLoader.sar</java>
  </module>
  <module>
    <ejb>Layer3MsgMdb.jar</ejb>
  </module>
  <module>
    <ejb>Common.jar</ejb>
  </module>
  <module>
    <ejb>Attributes.jar</ejb>
  </module>
  <module>
    <ejb>Data.jar</ejb>
  </module>
  <module>
    <ejb>Model.jar</ejb>
  </module>
  <module>
    <ejb>Users.jar</ejb>
  </module>
  <module>
    <ejb>Tasks.jar</ejb>
  </module>
  <module>
    <ejb>Survey.jar</ejb>
  </module>
  <module>
    <ejb>BenchmarkQpis.jar</ejb>
  </module>
  <module>
    <ejb>Cellrefutils.jar</ejb>
  </module>
  <module>
    <ejb>ConfigChanges.jar</ejb>
  </module>
  <module>
    <ejb>Engine.jar</ejb>
  </module>
  <module>
    <ejb>Events.jar</ejb>
  </module>
  <module>
    <ejb>QueryDefs.jar</ejb>
  </module>
  <module>
    <ejb>QueryData.jar</ejb>
  </module>
  <module>
    <ejb>GeoTagging.jar</ejb>
  </module>
  <module>
    <ejb>Kpievents.jar</ejb>
  </module>
  <module>
    <ejb>Modules.jar</ejb>
  </module>
  <module>
    <ejb>Network.jar</ejb>
  </module>
  <module>
    <ejb>Qpis.jar</ejb>
  </module>
  <module>
    <ejb>RadioNetworkAnalysis.jar</ejb>
  </module>
  <module>
    <ejb>VirtualEarth.jar</ejb>
  </module>
  <module>
    <ejb>WMS.jar</ejb>
  </module>
  <module>
    <ejb>ReportData.jar</ejb>
  </module>
  <module>
    <ejb>ReportsMetadata.jar</ejb>
  </module>
  <module>
    <ejb>ReportProducer.jar</ejb>
  </module>
  <module>
    <web>
      <web-uri>Quorre.war</web-uri>
      <context-root>ActixOne/Quorre</context-root>
    </web>
  </module>
  <module>
    <web>
      <web-uri>TestWar.war</web-uri>
      <context-root>TestWar</context-root>
    </web>
  </module>
  <module>
    <web>
      <web-uri>Download.war</web-uri>
      <context-root>ActixOne/Download</context-root>
    </web>
  </module>
</application>

Exception:

2009-07-10 12:28:30,687 INFO  [org.jboss.ejb3.EJB3Deployer] Deployed: file:/C:/jboss-4.2/server/default/tmp/deploy/tmp4660403835223254272ActixOne.ear-contents/ReportProducer.jar
2009-07-10 12:28:30,687 INFO  [org.jboss.web.tomcat.service.TomcatDeployer] deploy, ctxPath=/ActixOne/Quorre, warUrl=.../tmp/deploy/tmp4660403835223254272ActixOne.ear-contents/Quorre-exp.war/
2009-07-10 12:28:30,875 INFO  [org.rhq.helpers.rtfilter.filter.RtFilter] Initialized response-time filter for webapp with context root 'ActixOne/Quorre'.
2009-07-10 12:28:31,687 INFO  [org.jboss.web.tomcat.service.TomcatDeployer] deploy, ctxPath=/TestWar, warUrl=.../tmp/deploy/tmp4660403835223254272ActixOne.ear-contents/TestWar-exp.war/
2009-07-10 12:28:31,687 WARN  [org.jboss.system.ServiceController] Problem starting service jboss.web.deployment:war=TestWar.war,id=2043149425
org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)
	at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:384)
	at org.jboss.web.WebModule.startModule(WebModule.java:83)
	at org.jboss.web.WebModule.startService(WebModule.java:61)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
	at $Proxy0.start(Unknown Source)
	at org.jboss.system.ServiceController.start(ServiceController.java:417)
	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.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 $Proxy45.start(Unknown Source)
	at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:466)
	at sun.reflect.GeneratedMethodAccessor85.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
	at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
	at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:87)
	at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
	at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
	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 $Proxy46.start(Unknown Source)
	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
	at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.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(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
	at $Proxy0.start(Unknown Source)
	at org.jboss.system.ServiceController.start(ServiceController.java:417)
	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.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:304)
	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(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.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(Unknown Source)
Caused by: javax.naming.NameAlreadyBoundException
	at org.jnp.server.NamingServer.bind(NamingServer.java:144)
	at org.jnp.interfaces.NamingContext.bind(NamingContext.java:591)
	at org.jnp.interfaces.NamingContext.bind(NamingContext.java:552)
	at org.jboss.web.AbstractWebDeployer.parseWebAppDescriptors(AbstractWebDeployer.java:495)
	at org.jboss.web.AbstractWebDeployer$DescriptorParser.parseWebAppDescriptors(AbstractWebDeployer.java:878)
	at org.jboss.web.tomcat.service.TomcatDeployer.performDeployInternal(TomcatDeployer.java:159)
	at org.jboss.web.tomcat.service.TomcatDeployer.performDeploy(TomcatDeployer.java:104)
	at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:375)
	... 112 more
2009-07-10 12:28:31,718 ERROR [org.jboss.deployment.MainDeployer] Could not start deployment: file:/C:/jboss-4.2/server/default/tmp/deploy/tmp4660403835223254272ActixOne.ear-contents/TestWar.war
org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)
	at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:384)
	at org.jboss.web.WebModule.startModule(WebModule.java:83)
	at org.jboss.web.WebModule.startService(WebModule.java:61)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
	at $Proxy0.start(Unknown Source)
	at org.jboss.system.ServiceController.start(ServiceController.java:417)
	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.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 $Proxy45.start(Unknown Source)
	at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:466)
	at sun.reflect.GeneratedMethodAccessor85.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
	at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
	at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:87)
	at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
	at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
	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 $Proxy46.start(Unknown Source)
	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
	at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.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(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
	at $Proxy0.start(Unknown Source)
	at org.jboss.system.ServiceController.start(ServiceController.java:417)
	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.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:304)
	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(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.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(Unknown Source)
Caused by: javax.naming.NameAlreadyBoundException
	at org.jnp.server.NamingServer.bind(NamingServer.java:144)
	at org.jnp.interfaces.NamingContext.bind(NamingContext.java:591)
	at org.jnp.interfaces.NamingContext.bind(NamingContext.java:552)
	at org.jboss.web.AbstractWebDeployer.parseWebAppDescriptors(AbstractWebDeployer.java:495)
	at org.jboss.web.AbstractWebDeployer$DescriptorParser.parseWebAppDescriptors(AbstractWebDeployer.java:878)
	at org.jboss.web.tomcat.service.TomcatDeployer.performDeployInternal(TomcatDeployer.java:159)
	at org.jboss.web.tomcat.service.TomcatDeployer.performDeploy(TomcatDeployer.java:104)
	at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:375)
	... 112 more
2009-07-10 12:28:31,718 ERROR [org.jboss.deployment.scanner.URLDeploymentScanner] Incomplete Deployment listing:

--- Incompletely deployed packages ---
org.jboss.deployment.DeploymentInfo at 11dba24c { url=file:/C:/jboss-4.2/server/default/deploy/ActixOne.ear }
  deployer: org.jboss.deployment.EARDeployer at 7981d5
  status: Deployment FAILED reason: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)
  state: FAILED
  watch: file:/C:/jboss-4.2/server/default/deploy/ActixOne.ear
  altDD: null
  lastDeployed: 1247225246750
  lastModified: 1247225222906
  mbeans:
    jboss.j2ee:ear=ActixOne.ear,jar=Admin.jar,name=Admin,service=EJB3 state: Started
    persistence.units:ear=ActixOne.ear,jar=Settings.jar,unitName=SettingsStorage state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Settings.jar,name=Settings,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Layer3Msg.jar,name=Layer3Msg,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Layer3MsgMdb.jar,name=ReportProducerMDB,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Common.jar,name=Common,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Attributes.jar,name=Attributes,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Data.jar,name=Data,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Model.jar,name=Model,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Users.jar,name=Users,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Tasks.jar,name=Tasks,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Survey.jar,name=Survey,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=BenchmarkQpis.jar,name=Benchmarkqpis,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Cellrefutils.jar,name=Cellrefutils,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=ConfigChanges.jar,name=Configchanges,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Engine.jar,name=Engine,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Events.jar,name=Events,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=QueryDefs.jar,name=QueryDefs,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=QueryData.jar,name=QueryData,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=GeoTagging.jar,name=Geotagging,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Kpievents.jar,name=Kpievents,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Modules.jar,name=Modules,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Network.jar,name=Network,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Qpis.jar,name=Qpis,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=RadioNetworkAnalysis.jar,name=RadioNetworkAnalysis,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=VirtualEarth.jar,name=VirtualEarth,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=WMS.jar,name=Wms,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=ReportData.jar,name=ReportData,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=ReportsMetadata.jar,name=ReportsMetadata,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=ReportProducer.jar,name=ReportProducerMDB,service=EJB3 state: Started

--- MBeans waiting for other MBeans ---
ObjectName: jboss:service=KeyGeneratorFactory,type=HiLo
  State: CONFIGURED
  I Depend On:
    jboss:service=TransactionManager
    jboss.jca:service=DataSourceBinding,name=DefaultDS

ObjectName: jboss.cache:service=InvalidationBridge,type=JavaGroups
  State: CONFIGURED
  I Depend On:
    jboss:service=DefaultPartition
    jboss.cache:service=InvalidationManager

ObjectName: jboss.mq:service=InvocationLayer,type=HTTP
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=Invoker
    jboss.web:service=WebServer

ObjectName: jboss.mq:service=StateManager
  State: CONFIGURED
  I Depend On:
    jboss.jca:service=DataSourceBinding,name=DefaultDS
  Depends On Me:
    jboss.mq:service=DestinationManager

ObjectName: jboss.mq:service=DestinationManager
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=MessageCache
    jboss.mq:service=PersistenceManager
    jboss.mq:service=StateManager
    jboss.mq:service=ThreadPool
    jboss:service=Naming
  Depends On Me:
    jboss.mq.destination:service=Topic,name=testTopic
    jboss.mq.destination:service=Topic,name=securedTopic
    jboss.mq.destination:service=Topic,name=testDurableTopic
    jboss.mq.destination:service=Queue,name=testQueue
    jboss.mq.destination:service=Queue,name=A
    jboss.mq.destination:service=Queue,name=B
    jboss.mq.destination:service=Queue,name=C
    jboss.mq.destination:service=Queue,name=D
    jboss.mq.destination:service=Queue,name=ex
    jboss.mq:service=SecurityManager
    jboss.mq.destination:service=Queue,name=DLQ

ObjectName: jboss.mq:service=PersistenceManager
  State: CONFIGURED
  I Depend On:
    jboss.jca:service=DataSourceBinding,name=DefaultDS
  Depends On Me:
    jboss.mq:service=DestinationManager

ObjectName: jboss.mq.destination:service=Topic,name=testTopic
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager
    jboss.mq:service=SecurityManager

ObjectName: jboss.mq.destination:service=Topic,name=securedTopic
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager
    jboss.mq:service=SecurityManager

ObjectName: jboss.mq.destination:service=Topic,name=testDurableTopic
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager
    jboss.mq:service=SecurityManager

ObjectName: jboss.mq.destination:service=Queue,name=testQueue
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager
    jboss.mq:service=SecurityManager

ObjectName: jboss.mq.destination:service=Queue,name=A
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager

ObjectName: jboss.mq.destination:service=Queue,name=B
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager

ObjectName: jboss.mq.destination:service=Queue,name=C
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager

ObjectName: jboss.mq.destination:service=Queue,name=D
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager

ObjectName: jboss.mq.destination:service=Queue,name=ex
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager

ObjectName: jboss.mq:service=Invoker
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=TracingInterceptor
    jboss:service=Naming
  Depends On Me:
    jboss.mq:service=InvocationLayer,type=HTTP
    jboss.mq:service=InvocationLayer,type=JVM
    jboss.mq:service=InvocationLayer,type=UIL2

ObjectName: jboss.mq:service=TracingInterceptor
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=SecurityManager
  Depends On Me:
    jboss.mq:service=Invoker

ObjectName: jboss.mq:service=SecurityManager
  State: CONFIGURED
  I Depend On:
    jboss.security:service=JaasSecurityManager
    jboss.mq:service=DestinationManager
  Depends On Me:
    jboss.mq.destination:service=Topic,name=testTopic
    jboss.mq.destination:service=Topic,name=securedTopic
    jboss.mq.destination:service=Topic,name=testDurableTopic
    jboss.mq.destination:service=Queue,name=testQueue
    jboss.mq:service=TracingInterceptor
    jboss.mq.destination:service=Queue,name=DLQ

ObjectName: jboss.mq.destination:service=Queue,name=DLQ
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager
    jboss.mq:service=SecurityManager

ObjectName: jboss.mq:service=InvocationLayer,type=JVM
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=Invoker

ObjectName: jboss.mq:service=InvocationLayer,type=UIL2
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=Invoker

ObjectName: jboss.web.deployment:war=TestWar.war,id=2043149425
  State: FAILED
  Reason: org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)

--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.web.deployment:war=TestWar.war,id=2043149425
  State: FAILED
  Reason: org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)

ObjectName: jboss.cache:service=InvalidationManager
  State: NOTYETINSTALLED
  Depends On Me:
    jboss.cache:service=InvalidationBridge,type=JavaGroups

ObjectName: jboss.jca:service=DataSourceBinding,name=DefaultDS
  State: NOTYETINSTALLED
  Depends On Me:
    jboss:service=KeyGeneratorFactory,type=HiLo
    jboss.mq:service=StateManager
    jboss.mq:service=PersistenceManager

*********************************************************************

I found out that I'm not the only one with problem like that:
http://www.techienuggets.com/Detail?tx=27457

Regards,
Michal Rorat

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

        


From jira-events at lists.jboss.org  Fri Jul 10 10:00:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Fri, 10 Jul 2009 10:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7088) expressions like
 'ne', 'eq' are not working in jboss
In-Reply-To: <170839805.1247141429138.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <861623540.1247234429357.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert resolved JBAS-7088.
--------------------------------

    Resolution: Rejected


This all works as expected.  Execute attachment in JSFUNIT-221.

> expressions like 'ne','eq' are not working in jboss
> ---------------------------------------------------
>
>                 Key: JBAS-7088
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7088
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: windows
>            Reporter: anil kumar
>            Assignee: Stan Silvert
>
> <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
>               <h:column rendered="#{screenConfig.displayTitle ne 'dashboard'}">
>               <h:outputText  value="#{screenConfig.displayTitle}"> </h:outputText>
>                </h:column>
>   </h:dataTable>
>  expressions like 'ne','eq' are not working in jboss but its working fine in Glassfish.
>  please suggest me on fixing this issue.

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

        


From jira-events at lists.jboss.org  Fri Jul 10 10:04:29 2009
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 10 Jul 2009 10:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6627) The JMX console
 /MBean Inspector page doesn't handle org.w3c.dom.Element correctly
In-Reply-To: <24936943.1237209442677.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1450414136.1247234669156.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned JBAS-6627:
--------------------------------------

    Assignee:     (was: Darran Lofthouse)


> The JMX console /MBean Inspector page doesn't handle org.w3c.dom.Element correctly
> ----------------------------------------------------------------------------------
>
>                 Key: JBAS-6627
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6627
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX/Web Console
>    Affects Versions: JBossAS-4.2.3.GA
>            Reporter: Howard Gao
>
> When a mbean is opened in the MBeanInspector page, if the mbean has attributes that are of type org.w3c.dom.Element, the corresponding input field cannot display them correctly if the element's value contains special characters like ' (quote). Special characters in this case should be converted to html code in order to be displayed properly on the web browser.
> See related jira https://jira.jboss.org/jira/browse/JBMESSAGING-1517.

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

        


From jira-events at lists.jboss.org  Fri Jul 10 10:52:29 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Fri, 10 Jul 2009 10:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7094) JaasSecurityDomain
 fails to decrypt some PBE passwords
Message-ID: <1553321981.1247237549766.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JaasSecurityDomain fails to decrypt some PBE passwords
------------------------------------------------------

                 Key: JBAS-7094
                 URL: https://jira.jboss.org/jira/browse/JBAS-7094
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Marcus Moyses
            Assignee: Marcus Moyses
             Fix For: JBossAS-5.2.0.Beta1


Certain passwords when encrypted with PBE result in a String with leading zeros. These leading zeros are not printed with the String so decrypting the password fails because of invalid number of bytes. An exception is thrown:

javax.crypto.IllegalBlockSizeException: Input length (with padding) not multiple of 8 bytes

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

        


From jira-events at lists.jboss.org  Fri Jul 10 11:05:29 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Fri, 10 Jul 2009 11:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7094) JaasSecurityDomain
 fails to decrypt some PBE passwords
In-Reply-To: <1553321981.1247237549766.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1523791264.1247238329396.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcus Moyses resolved JBAS-7094.
---------------------------------

    Resolution: Done


Fixed leading zeros problem.

> JaasSecurityDomain fails to decrypt some PBE passwords
> ------------------------------------------------------
>
>                 Key: JBAS-7094
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7094
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Marcus Moyses
>            Assignee: Marcus Moyses
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Certain passwords when encrypted with PBE result in a String with leading zeros. These leading zeros are not printed with the String so decrypting the password fails because of invalid number of bytes. An exception is thrown:
> javax.crypto.IllegalBlockSizeException: Input length (with padding) not multiple of 8 bytes

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

        


From jira-events at lists.jboss.org  Fri Jul 10 11:05:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 10 Jul 2009 11:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1034799337.1247238329577.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475766#action_12475766 ] 

Ian Springer commented on EJBTHREE-1852:
----------------------------------------

Starting up a recent build of EAP5 with the 'all' config, I get 49 of the "EJBTHREE-1852: InterceptorInfoRepository is deprecated" warnings logged to the console:

http://pastebin.com/f78c3bb4

I think this is excessive. Can we do one of the following?

1) Change the code to throttle how often the warning is printed.
2) Change the level of the log message to DEBUG.
3) Change the log4j config to log messages from that class only at ERROR level be default.



> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>            Assignee: Carlo de Wolf
>             Fix For: 1.1.8
>
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

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

        


From jira-events at lists.jboss.org  Fri Jul 10 11:05:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 10 Jul 2009 11:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <69859154.1247238329785.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer reopened EJBTHREE-1852:
------------------------------------



> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>            Assignee: Carlo de Wolf
>             Fix For: 1.1.8
>
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

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

        


From jira-events at lists.jboss.org  Fri Jul 10 11:17:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Fri, 10 Jul 2009 11:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-203) Fix the state
 usage when doing Deployers::checkComplete
Message-ID: <635438890.1247239049671.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Fix the state usage when doing Deployers::checkComplete
-------------------------------------------------------

                 Key: JBDEPLOY-203
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-203
             Project: JBoss Deployers
          Issue Type: Bug
          Components: maindeployer
    Affects Versions: JBDEPLOY-2.0.8.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For:  JBDEPLOY-2.2.x


Currently we're using the wrong state to determine if some component is missing some dependency.
Instead of DependencyItem::getWhenRequired we should use getDependentState.

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

        


From jira-events at lists.jboss.org  Fri Jul 10 11:17:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 11:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <54633873.1247239049604.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475774#action_12475774 ] 

jaikiran pai commented on EJBTHREE-1852:
----------------------------------------

The EAP branch probably needs this  JBAS-7004. 

> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>            Assignee: Carlo de Wolf
>             Fix For: 1.1.8
>
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

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

        


From jira-events at lists.jboss.org  Fri Jul 10 11:49:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Fri, 10 Jul 2009 11:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-203) Fix the state
 usage when doing Deployers::checkComplete
In-Reply-To: <635438890.1247239049671.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <401788058.1247240969499.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBDEPLOY-203.
----------------------------------

    Resolution: Done


> Fix the state usage when doing Deployers::checkComplete
> -------------------------------------------------------
>
>                 Key: JBDEPLOY-203
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-203
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: maindeployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For:  JBDEPLOY-2.2.x
>
>
> Currently we're using the wrong state to determine if some component is missing some dependency.
> Instead of DependencyItem::getWhenRequired we should use getDependentState.

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

        


From jira-events at lists.jboss.org  Fri Jul 10 12:09:29 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 10 Jul 2009 12:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-204)
 DeployersImpl.checkComplete()
 should report asynchronous deployments differently
Message-ID: <366247431.1247242169112.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

DeployersImpl.checkComplete() should report asynchronous deployments differently
--------------------------------------------------------------------------------

                 Key: JBDEPLOY-204
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-204
             Project: JBoss Deployers
          Issue Type: Feature Request
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For:  JBDEPLOY-2.2.x




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

        


From jira-events at lists.jboss.org  Fri Jul 10 12:11:29 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 10 Jul 2009 12:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBDEPLOY-204)
 DeployersImpl.checkComplete()
 should report asynchronous deployments in progress differently
In-Reply-To: <366247431.1247242169112.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1188016163.1247242289409.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed JBDEPLOY-204.
-------------------------------

    Resolution: Done


> DeployersImpl.checkComplete() should report asynchronous deployments in progress differently
> --------------------------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-204
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-204
>             Project: JBoss Deployers
>          Issue Type: Feature Request
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For:  JBDEPLOY-2.2.x
>
>


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

        


From jira-events at lists.jboss.org  Fri Jul 10 12:11:29 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 10 Jul 2009 12:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBDEPLOY-204)
 DeployersImpl.checkComplete()
 should report asynchronous deployments in progress differently
In-Reply-To: <366247431.1247242169112.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <238958568.1247242289344.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated JBDEPLOY-204:
--------------------------------

    Summary: DeployersImpl.checkComplete() should report asynchronous deployments in progress differently  (was: DeployersImpl.checkComplete() should report asynchronous deployments differently)


> DeployersImpl.checkComplete() should report asynchronous deployments in progress differently
> --------------------------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-204
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-204
>             Project: JBoss Deployers
>          Issue Type: Feature Request
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For:  JBDEPLOY-2.2.x
>
>


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

        


From jira-events at lists.jboss.org  Fri Jul 10 12:25:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 10 Jul 2009 12:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2202) Generated types
 should be Serializable
In-Reply-To: <1963762277.1247174669126.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1346957251.1247243129187.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2202.
----------------------------------

    Resolution: Done


Fixed. Thanks for reporting.

> Generated types should be Serializable
> --------------------------------------
>
>                 Key: JBRULES-2202
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2202
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler, drools-core
>    Affects Versions: 5.0.0.FINAL, 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> Hello,
> Recently I've been working with Drools version 5.0.1 to set up an event processor.  While doing so I have come
> across difficulties with the accumulate function, in that it will always throw a ClassCastException
> when inserting events that are declared within my drl file.  To illustrate this I've set up an example which is
> shown below.  I've search Google and the mailing list for several hours, but the only way past this problem
> appears to be that I will have to declare a class externally and make sure it implements Serializable.  Does
> anyone has suggestions for another approach?  Secondly, I would have assumed that since Drools was
> compiling these internally declared classes, that Serializable would have been implemented automatically.  So
> is this a result of the generated class not implementing Serializable, or have I missed something in my rules
> file?  Thanks.
> The important part of my drl file is:
> declare TestEvent
>    @role( event )
>    @expires(10s)
>    id : String
> end
> #This rule works fine when 'Accumulate Count' is commented out, and is used to make
> #sure that the event inserting has worked.
> rule "Is It There"
>     when
>         TestEvent() from entry-point "test"
>     then
>         System.out.println("Found a TestEvent.");
> end
> #This rule throws a ClassCastException when a TestEvent is inserted.
> rule "Accumulate Count"
>     when
>         $n : Number() from accumulate($t : TestEvent() from entry-point "test",    count($t))
>     then
>         System.out.println("Found " + $n + " events.");
> end
> The unit test does this:
> FactType testEventType = session.getKnowledgeBase().getFactType("com.drools.test", "TestEvent");
> for(int i = 0; i < 10; i++){
>     Object testEvent = testEventType.newInstance();
>     testEventType.set(testEvent, "id", "id");
>     WorkingMemoryEntryPoint mainStream = session.getWorkingMemoryEntryPoint("test");
>     mainStream.insert(event);
>     session.fireAllRules();
> }
> The exception I receive is:
> org.drools.RuntimeDroolsException: java.lang.ClassCastException: com.drools.test.TestEvent cannot be cast to java.io.Serializable
>     at org.drools.rule.Accumulate.accumulate(Accumulate.java:172)
>     at org.drools.reteoo.AccumulateNode.modifyTuple(AccumulateNode.java:424)
>     at org.drools.reteoo.AccumulateNode.assertObject(AccumulateNode.java:284)
>     at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:42)
>     at org.drools.reteoo.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:326)
>     at org.drools.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:221)
>     at org.drools.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:394)
>     at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1486)
>     at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:158)
>     at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:122)
>     at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:80)
>     at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:28)
>     at com.drools.test.MyUnitTest.testEvents(EvaluationTest.java:66)
>     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.springframework.test.context.junit4.SpringTestMethod.invoke(SpringTestMethod.java:160)
>     at org.springframework.test.context.junit4.SpringMethodRoadie.runTestMethod(SpringMethodRoadie.java:233)
>     at org.springframework.test.context.junit4.SpringMethodRoadie$RunBeforesThenTestThenAfters.run(SpringMethodRoadie.java:333)
>     at org.springframework.test.context.junit4.SpringMethodRoadie.runWithRepetitions(SpringMethodRoadie.java:217)
>     at org.springframework.test.context.junit4.SpringMethodRoadie.runTest(SpringMethodRoadie.java:197)
>     at org.springframework.test.context.junit4.SpringMethodRoadie.run(SpringMethodRoadie.java:143)
>     at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.invokeTestMethod(SpringJUnit4ClassRunner.java:160)
>     at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
>     at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
>     at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
>     at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
>     at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
>     at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:97)
>     at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
>     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)
> Caused by: java.lang.ClassCastException: com.drools.test.TestEvent cannot be cast to java.io.Serializable
>     at org.drools.base.accumulators.JavaAccumulatorFunctionExecutor.accumulate(JavaAccumulatorFunctionExecutor.java:110)
>     at org.drools.rule.Accumulate.accumulate(Accumulate.java:164)
>     ... 36 more

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

        


From jira-events at lists.jboss.org  Fri Jul 10 12:45:29 2009
From: jira-events at lists.jboss.org (Konstantin Pupkov (JIRA))
Date: Fri, 10 Jul 2009 12:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1354090614.1247244329248.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475794#action_12475794 ] 

Konstantin Pupkov commented on JBMESSAGING-1681:
------------------------------------------------

Well,
I don't come up with jboss' forums+products+packages... structures. I just want to improve product itself. From my prospective you are one team. I think jboss need to improve internal communications to avoid situations like that. 
When I will have time I can rise that issue in other forum group, but I guess you can do that faster. Just reassign this issue to other team what ever it is.


Konstantin  

P.S. Thank you for quick respond and help!

> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

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

        


From jira-events at lists.jboss.org  Fri Jul 10 13:26:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 10 Jul 2009 13:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
In-Reply-To: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1342014959.1247246789811.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7051:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: EmbJopr1_3 ProfileService)


> ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7051
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ejb3-tutorial-mdb.jar
>
>
> This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:
> 1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.
> 2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:
> container=JBossMQ|JBossMessaging
> which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.
> Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:
> 15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
> ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
> rvice=Queue, parent=JBoss EAP 5 (default)]
> org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
>         at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
>         at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
> rceManager.java:235)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
> figurationUIBean.java:144)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.seam.util.Reflections.invoke(Reflections.java:22)
>         at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
>         at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
> tion(ResourceConfigurationUIBean_$$_javassist_12.java)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
>         at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
>         at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
>         at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
>         at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
>         at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
>         at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
>         at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
>         at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
>         at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
>         at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>         at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>         at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
>         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:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
> a:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
> :70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
> operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
> a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
> ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
> ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
>         ... 84 more

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

        


From jira-events at lists.jboss.org  Fri Jul 10 13:26:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 10 Jul 2009 13:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
In-Reply-To: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1319844970.1247246789520.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer reopened JBAS-7051:
--------------------------------



Looks like there are still some mapping issues for the managed properties. When I go the Configuration tab in the admin console for a JBossMQ queue, I get an error on the page and the following exception in the server log:

 13:19:35,767 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
ueue, key=queue/tutorial/defaultedexample, name=queue/tutorial/defaultedexample, parent=JBoss EAP 5 (default)]
org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [Queue Resource with id [-
37].
        at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
        at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
rceManager.java:235)
        at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
figurationUIBean.java:144)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.jboss.seam.util.Reflections.invoke(Reflections.java:22)
        at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
        at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
        at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
        at org.jboss.seam.core.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
        at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
        at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
        at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
        at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
        at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
tion(ResourceConfigurationUIBean_$$_javassist_12.java)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
        at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
        at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
        at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
        at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
        at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
        at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
        at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
        at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
        at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
        at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
        at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
        at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
        at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
        at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
        at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
        at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
        at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
        at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
        at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
        at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
        at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
        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:235)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
a:126)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
:70)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.RuntimeException: [Warning] java.lang.reflect.UndeclaredThrowableException:Failed to get property '
consumerCount' on component 'jboss.mq.destination:name=defaultedtutorial,service=Queue'. -> javax.management.AttributeNo
tFoundException:not found: ConsumerCount
        ... 84 more


> ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7051
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ejb3-tutorial-mdb.jar
>
>
> This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:
> 1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.
> 2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:
> container=JBossMQ|JBossMessaging
> which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.
> Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:
> 15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
> ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
> rvice=Queue, parent=JBoss EAP 5 (default)]
> org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
>         at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
>         at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
> rceManager.java:235)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
> figurationUIBean.java:144)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.seam.util.Reflections.invoke(Reflections.java:22)
>         at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
>         at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
> tion(ResourceConfigurationUIBean_$$_javassist_12.java)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
>         at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
>         at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
>         at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
>         at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
>         at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
>         at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
>         at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
>         at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
>         at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
>         at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>         at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>         at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
>         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:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
> a:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
> :70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
> operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
> a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
> ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
> ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
>         ... 84 more

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

        


From jira-events at lists.jboss.org  Fri Jul 10 13:30:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 10 Jul 2009 13:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
In-Reply-To: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <780380837.1247247029670.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475803#action_12475803 ] 

Ian Springer commented on JBAS-7051:
------------------------------------

Similarly, when I go to the Metrics tab for a JBossMQ queue, only the Message Count metric is displayed. All of the other metrics fail to be retrieved, and the following exceptions are dumped to the server log:

13:25:56,641 ERROR [JmsDestinationComponent] Failed to collect metric for MeasurementScheduleRequest[scheduleId=1, name=
deliveringCount, interval=0, enabled=true, dataType=MEASUREMENT, rawNumericType=null]
java.lang.reflect.UndeclaredThrowableException: Failed to get property 'deliveringCount' on component 'jboss.mq.destinat
ion:name=defaultedtutorial,service=Queue'.
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:119)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:278)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.management.AttributeNotFoundException: not found: DeliveringCount
        at org.jboss.mx.server.AbstractMBeanInvoker.getAttribute(AbstractMBeanInvoker.java:335)
        at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:565)
        at org.jboss.system.microcontainer.ServiceControllerContext.get(ServiceControllerContext.java:179)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:80)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:83)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:53)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.get(BasicKernelBus.java:76)
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:90)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:278)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 19 more
13:25:56,876 ERROR [JmsDestinationComponent] Failed to collect metric for MeasurementScheduleRequest[scheduleId=1, name=
messageStatistics.depth, interval=0, enabled=true, dataType=MEASUREMENT, rawNumericType=null]
java.lang.reflect.UndeclaredThrowableException: Failed to get property 'messageStatistics' on component 'jboss.mq.destin
ation:name=defaultedtutorial,service=Queue'.
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:119)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.management.AttributeNotFoundException: not found: MessageStatistics
        at org.jboss.mx.server.AbstractMBeanInvoker.getAttribute(AbstractMBeanInvoker.java:335)
        at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:565)
        at org.jboss.system.microcontainer.ServiceControllerContext.get(ServiceControllerContext.java:179)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:80)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:83)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:53)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.get(BasicKernelBus.java:76)
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:90)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 19 more
13:25:57,048 ERROR [JmsDestinationComponent] Failed to collect metric for MeasurementScheduleRequest[scheduleId=1, name=
messageStatistics.count, interval=0, enabled=true, dataType=MEASUREMENT, rawNumericType=null]
java.lang.reflect.UndeclaredThrowableException: Failed to get property 'messageStatistics' on component 'jboss.mq.destin
ation:name=defaultedtutorial,service=Queue'.
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:119)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.management.AttributeNotFoundException: not found: MessageStatistics
        at org.jboss.mx.server.AbstractMBeanInvoker.getAttribute(AbstractMBeanInvoker.java:335)
        at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:565)
        at org.jboss.system.microcontainer.ServiceControllerContext.get(ServiceControllerContext.java:179)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:80)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:83)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:53)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.get(BasicKernelBus.java:76)
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:90)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 19 more
13:25:57,079 ERROR [JmsDestinationComponent] Failed to collect metric for MeasurementScheduleRequest[scheduleId=1, name=
consumerCount, interval=0, enabled=true, dataType=MEASUREMENT, rawNumericType=null]
java.lang.reflect.UndeclaredThrowableException: Failed to get property 'consumerCount' on component 'jboss.mq.destinatio
n:name=defaultedtutorial,service=Queue'.
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:119)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:278)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.management.AttributeNotFoundException: not found: ConsumerCount
        at org.jboss.mx.server.AbstractMBeanInvoker.getAttribute(AbstractMBeanInvoker.java:335)
        at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:565)
        at org.jboss.system.microcontainer.ServiceControllerContext.get(ServiceControllerContext.java:179)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:80)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:83)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:53)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.get(BasicKernelBus.java:76)
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:90)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:278)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 19 more
13:25:57,110 ERROR [JmsDestinationComponent] Failed to collect metric for MeasurementScheduleRequest[scheduleId=1, name=
messageStatistics.countDelta, interval=0, enabled=true, dataType=MEASUREMENT, rawNumericType=null]
java.lang.reflect.UndeclaredThrowableException: Failed to get property 'messageStatistics' on component 'jboss.mq.destin
ation:name=defaultedtutorial,service=Queue'.
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:119)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.management.AttributeNotFoundException: not found: MessageStatistics
        at org.jboss.mx.server.AbstractMBeanInvoker.getAttribute(AbstractMBeanInvoker.java:335)
        at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:565)
        at org.jboss.system.microcontainer.ServiceControllerContext.get(ServiceControllerContext.java:179)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:80)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:83)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:53)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.get(BasicKernelBus.java:76)
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:90)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 19 more
13:25:57,188 ERROR [JmsDestinationComponent] Failed to collect metric for MeasurementScheduleRequest[scheduleId=1, name=
scheduledMessageCount, interval=0, enabled=true, dataType=MEASUREMENT, rawNumericType=null]
java.lang.reflect.UndeclaredThrowableException: Failed to get property 'scheduledMessageCount' on component 'jboss.mq.de
stination:name=defaultedtutorial,service=Queue'.
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:119)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:278)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.management.AttributeNotFoundException: not found: ScheduledMessageCount
        at org.jboss.mx.server.AbstractMBeanInvoker.getAttribute(AbstractMBeanInvoker.java:335)
        at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:565)
        at org.jboss.system.microcontainer.ServiceControllerContext.get(ServiceControllerContext.java:179)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:80)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:83)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:53)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.get(BasicKernelBus.java:76)
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:90)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:278)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 19 more
13:25:57,266 ERROR [JmsDestinationComponent] Failed to collect metric for MeasurementScheduleRequest[scheduleId=1, name=
messageStatistics.timeLastUpdate, interval=0, enabled=true, dataType=MEASUREMENT, rawNumericType=null]
java.lang.reflect.UndeclaredThrowableException: Failed to get property 'messageStatistics' on component 'jboss.mq.destin
ation:name=defaultedtutorial,service=Queue'.
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:119)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.management.AttributeNotFoundException: not found: MessageStatistics
        at org.jboss.mx.server.AbstractMBeanInvoker.getAttribute(AbstractMBeanInvoker.java:335)
        at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:565)
        at org.jboss.system.microcontainer.ServiceControllerContext.get(ServiceControllerContext.java:179)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:80)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:83)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:53)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.get(BasicKernelBus.java:76)
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:90)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 19 more
13:25:57,329 ERROR [JmsDestinationComponent] Failed to collect metric for MeasurementScheduleRequest[scheduleId=1, name=
messageStatistics.depthDelta, interval=0, enabled=true, dataType=MEASUREMENT, rawNumericType=null]
java.lang.reflect.UndeclaredThrowableException: Failed to get property 'messageStatistics' on component 'jboss.mq.destin
ation:name=defaultedtutorial,service=Queue'.
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:119)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.management.AttributeNotFoundException: not found: MessageStatistics
        at org.jboss.mx.server.AbstractMBeanInvoker.getAttribute(AbstractMBeanInvoker.java:335)
        at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:565)
        at org.jboss.system.microcontainer.ServiceControllerContext.get(ServiceControllerContext.java:179)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:80)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:83)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:53)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.get(BasicKernelBus.java:76)
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:90)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 19 more


> ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7051
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ejb3-tutorial-mdb.jar
>
>
> This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:
> 1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.
> 2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:
> container=JBossMQ|JBossMessaging
> which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.
> Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:
> 15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
> ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
> rvice=Queue, parent=JBoss EAP 5 (default)]
> org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
>         at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
>         at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
> rceManager.java:235)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
> figurationUIBean.java:144)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.seam.util.Reflections.invoke(Reflections.java:22)
>         at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
>         at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
> tion(ResourceConfigurationUIBean_$$_javassist_12.java)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
>         at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
>         at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
>         at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
>         at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
>         at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
>         at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
>         at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
>         at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
>         at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
>         at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>         at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>         at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
>         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:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
> a:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
> :70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
> operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
> a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
> ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
> ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
>         ... 84 more

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

        


From jira-events at lists.jboss.org  Fri Jul 10 14:51:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 10 Jul 2009 14:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-111) SJC: Temporary files
 must be deleted before deployment
Message-ID: <826257874.1247251889119.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC: Temporary files must be deleted before deployment
------------------------------------------------------

                 Key: JBJCA-111
                 URL: https://jira.jboss.org/jira/browse/JBJCA-111
             Project: JBoss JCA
          Issue Type: Bug
          Components: Deployer
    Affects Versions: 1.0.0.Alpha1
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Make sure that the temporary directory that resource adapters that are extracted to are cleaned up first.

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

        


From jira-events at lists.jboss.org  Fri Jul 10 14:53:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 10 Jul 2009 14:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-111) SJC: Temporary
 files must be deleted before deployment
In-Reply-To: <826257874.1247251889119.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <67214045.1247252009122.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-111.
-----------------------------------

    Resolution: Done


> SJC: Temporary files must be deleted before deployment
> ------------------------------------------------------
>
>                 Key: JBJCA-111
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-111
>             Project: JBoss JCA
>          Issue Type: Bug
>          Components: Deployer
>    Affects Versions: 1.0.0.Alpha1
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Make sure that the temporary directory that resource adapters that are extracted to are cleaned up first.

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

        


From jira-events at lists.jboss.org  Fri Jul 10 14:57:29 2009
From: jira-events at lists.jboss.org (Brad Hawthorne (JIRA))
Date: Fri, 10 Jul 2009 14:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1868) Calling remote
 interface on local bean results in remote invocation
Message-ID: <1481871457.1247252249106.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Calling remote interface on local bean results in remote invocation
-------------------------------------------------------------------

                 Key: EJBTHREE-1868
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1868
             Project: EJB 3.0
          Issue Type: Bug
          Components: ejb3
            Reporter: Brad Hawthorne


See forum thread for details

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

        


From jira-events at lists.jboss.org  Fri Jul 10 15:16:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 15:16:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1868) Calling remote
 interface on local bean results in remote invocation
In-Reply-To: <1481871457.1247252249106.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <484121670.1247253389461.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned EJBTHREE-1868:
--------------------------------------

    Assignee: jaikiran pai


> Calling remote interface on local bean results in remote invocation
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1868
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1868
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: ejb3
>            Reporter: Brad Hawthorne
>            Assignee: jaikiran pai
>
> See forum thread for details

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

        


From jira-events at lists.jboss.org  Fri Jul 10 15:18:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 15:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1868) Calling remote
 interface on local bean results in remote invocation
In-Reply-To: <1481871457.1247252249106.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <661472969.1247253509237.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1868:
-----------------------------------

    Component/s: proxy-impl
                     (was: ejb3)


> Calling remote interface on local bean results in remote invocation
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1868
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1868
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: proxy-impl
>            Reporter: Brad Hawthorne
>            Assignee: jaikiran pai
>
> See forum thread for details

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

        


From jira-events at lists.jboss.org  Fri Jul 10 15:20:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 15:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1868) Calling remote
 interface on local bean results in remote invocation
In-Reply-To: <1481871457.1247252249106.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <784432258.1247253629342.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475818#action_12475818 ] 

jaikiran pai commented on EJBTHREE-1868:
----------------------------------------

Will take a look. But if you have a simple application to reproduce this, then please attach it here. That will make things easier to reproduce.


> Calling remote interface on local bean results in remote invocation
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1868
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1868
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: proxy-impl
>            Reporter: Brad Hawthorne
>            Assignee: jaikiran pai
>
> See forum thread for details

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

        


From jira-events at lists.jboss.org  Fri Jul 10 15:23:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 10 Jul 2009 15:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-1143) CLONE [JBREM-877] -
 New Socket
 Connection is being Created for Every Client Request to the Server
Message-ID: <1703765675.1247253809257.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE [JBREM-877] - New Socket Connection is being Created for Every Client Request to the Server
-------------------------------------------------------------------------------------------------

                 Key: JBREM-1143
                 URL: https://jira.jboss.org/jira/browse/JBREM-1143
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: transport
    Affects Versions: 2.2.2.SP2
         Environment: Linux  os , Pentium duo Processor with 3.6 Ghz clock Speed, 4GB Ram in this Postgresql Database also Running
            Reporter: Kumarselvan Somasundaram
            Assignee: Ron Sigal
            Priority: Critical
             Fix For:  2.4.0.Beta2 (Pinto)


whenever  EJB3 client requests the Server new socket is being created. at the client side the socket connection pool is not being used. Hope there is some issue with the socket connection after getting response from the server,becoz of which the server side the connection is being closed. this increases the CPU utilization,

The same code is running fine in jboss 4.0.4 with jboss remoting 1.4.0

new remoting 2.2.2 SP4 only handling 1/4 of the load with high CPU utilization. 



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

        


From jira-events at lists.jboss.org  Fri Jul 10 15:26:45 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 10 Jul 2009 15:26:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-1143) CLONE [JBREM-877] -
 New Socket
 Connection is being Created for Every Client Request to the Server
In-Reply-To: <1703765675.1247253809257.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1838276016.1247254005889.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBREM-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ron Sigal updated JBREM-1143:
-----------------------------

                   Environment:     (was: Linux  os , Pentium duo Processor with 3.6 Ghz clock Speed, 4GB Ram in this Postgresql Database also Running)
                 Fix Version/s: 2.2.3.SP1
                                    (was:  2.4.0.Beta2 (Pinto))
             Affects Version/s: 2.2.3
                                    (was: 2.2.2.SP2)
                   Description: 
JBREM-877 is being cloned to port the feature back to the 2.2 branch.  The original description:

whenever  EJB3 client requests the Server new socket is being created. at the client side the socket connection pool is not being used. Hope there is some issue with the socket connection after getting response from the server,becoz of which the server side the connection is being closed. this increases the CPU utilization,

The same code is running fine in jboss 4.0.4 with jboss remoting 1.4.0

new remoting 2.2.2 SP4 only handling 1/4 of the load with high CPU utilization. 



  was:
whenever  EJB3 client requests the Server new socket is being created. at the client side the socket connection pool is not being used. Hope there is some issue with the socket connection after getting response from the server,becoz of which the server side the connection is being closed. this increases the CPU utilization,

The same code is running fine in jboss 4.0.4 with jboss remoting 1.4.0

new remoting 2.2.2 SP4 only handling 1/4 of the load with high CPU utilization. 



                      Priority: Major  (was: Critical)


> CLONE [JBREM-877] - New Socket Connection is being Created for Every Client Request to the Server
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBREM-1143
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1143
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 2.2.3
>            Reporter: Kumarselvan Somasundaram
>            Assignee: Ron Sigal
>             Fix For: 2.2.3.SP1
>
>
> JBREM-877 is being cloned to port the feature back to the 2.2 branch.  The original description:
> whenever  EJB3 client requests the Server new socket is being created. at the client side the socket connection pool is not being used. Hope there is some issue with the socket connection after getting response from the server,becoz of which the server side the connection is being closed. this increases the CPU utilization,
> The same code is running fine in jboss 4.0.4 with jboss remoting 1.4.0
> new remoting 2.2.2 SP4 only handling 1/4 of the load with high CPU utilization. 

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

        


From jira-events at lists.jboss.org  Fri Jul 10 15:52:29 2009
From: jira-events at lists.jboss.org (Brad Hawthorne (JIRA))
Date: Fri, 10 Jul 2009 15:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1868) Calling remote
 interface on local bean results in remote invocation
In-Reply-To: <1481871457.1247252249106.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <429705188.1247255549146.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475821#action_12475821 ] 

Brad Hawthorne commented on EJBTHREE-1868:
------------------------------------------

Sorry, I don't have anything simple prepared, I'll come up with something if you have troubles. 

Consider this unit test case though. If we make isLocal() public to simplify the test:

assertTrue("Invocations on singleton interceptor should be local", IsLocalProxyFactoryInterceptor.singleton.isLocal());

This currently fails. From what I understand by reading the code, it uses the system time of when the class was initialized to determine if it was created in the same vm. The singleton gets a stamp value of zero and thus is never considered local.

> Calling remote interface on local bean results in remote invocation
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1868
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1868
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: proxy-impl
>            Reporter: Brad Hawthorne
>            Assignee: jaikiran pai
>
> See forum thread for details

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

        


From jira-events at lists.jboss.org  Fri Jul 10 16:17:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 10 Jul 2009 16:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-1139) Modify PortUtil to
 allow a
 configurable range for MIN_UNPRIVILEGED_PORT and MAX_LEGAL_PORT.
In-Reply-To: <215395097.1246517211483.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2069166661.1247257049361.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBREM-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ron Sigal updated JBREM-1139:
-----------------------------

        Fix Version/s: 2.5.2 (Flounder)
                       2.2.3.SP1
    Affects Version/s: 2.2.3
                       2.5.1 (Flounder)
                           (was: 2.2.2.SP8)
             Assignee: Ron Sigal


> Modify PortUtil to allow a configurable range for MIN_UNPRIVILEGED_PORT and MAX_LEGAL_PORT.
> -------------------------------------------------------------------------------------------
>
>                 Key: JBREM-1139
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1139
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.5.1 (Flounder), 2.2.3
>            Reporter: Colin Mondesir
>            Assignee: Ron Sigal
>             Fix For: 2.5.2 (Flounder), 2.2.3.SP1
>
>
> PortUtil could be improved to read the port range configuration.
> This is straightforward and no side effect is expected.  However,
> PortUtil and its callers will need some refactoring as it is just a
> static utility classes currently.

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

        


From jira-events at lists.jboss.org  Fri Jul 10 17:05:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 10 Jul 2009 17:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-1144) Extend connection
 identity to server side
Message-ID: <480005843.1247259929160.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Extend connection identity to server side
-----------------------------------------

                 Key: JBREM-1144
                 URL: https://jira.jboss.org/jira/browse/JBREM-1144
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.3, 2.5.1 (Flounder)
            Reporter: Ron Sigal
            Assignee: Ron Sigal
             Fix For: 2.5.2 (Flounder), 2.2.3.SP1


In JBREM-1128 "Introduce connection identity concept" and JBREM-1132 "CLONE [JBREM-1128] - Introduce connection identity concept", the server was equipped to recognized when a client had been replaced by another client.  In other words, clients were assigned an identity.  This concept should be extended to the server side, so that ConnectionValidator can detect that a server has been replaced.

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

        


From jira-events at lists.jboss.org  Fri Jul 10 18:35:40 2009
From: jira-events at lists.jboss.org (Tom Murphy (JIRA))
Date: Fri, 10 Jul 2009 18:35:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2204) Exception not
 rethrown by AbstractWorkingMemory.executeQueuedActions()
Message-ID: <1550042503.1247265340995.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Exception not rethrown by AbstractWorkingMemory.executeQueuedActions() 
-----------------------------------------------------------------------

                 Key: JBRULES-2204
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2204
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
         Environment: JBoss AS 5.0, Windows Server 2003 SP2, Drools 5.0.1.FINAL
            Reporter: Tom Murphy
            Assignee: Mark Proctor


AbstractWorkingMemory.executeQueuedActions()  catches exceptions thrown within calls to action.execute() (line 1486). 

It then tests to see if the exception is a RuntimeDroolsException and rethrows it if it is. However, if it is not, it simply does a printStackTrace() on the exception and does not re-throw it. This is a problem because SplitInstance throws an IllegalArgumentException on line 73. This is then caught and gobbled by the catch clause starting on line 1487 of AbstractWorkingMemory.java. 

The result is that any service or application hosting the Drools runtime will never see this exception. What looks to the user like a clean (albeit overly shortened) rules session has in fact thrown an error, but it is not visible to the user or the owning service. It is therefore very difficult to diagnose why the rules and/or flows are not doing what they should.

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

        


From jira-events at lists.jboss.org  Fri Jul 10 21:44:29 2009
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 10 Jul 2009 21:44:29 -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: <868747971.1247276669270.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/GPD-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475867#action_12475867 ] 

Ronald van Kuijk commented on GPD-35:
-------------------------------------

I know the GPD is GEF, not GMF but http://publib.boulder.ibm.com/infocenter/rsmhelp/v7r0m0/index.jsp?topic=/org.eclipse.gmf.doc/tutorials/diagram/createConnection.html is what is 'needed' for a much better user experience. Maybe time for a change ;-)

> enhancement drawing transitions
> -------------------------------
>
>                 Key: GPD-35
>                 URL: https://jira.jboss.org/jira/browse/GPD-35
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>            Reporter: 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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 21:46:29 2009
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 10 Jul 2009 21:46:29 -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: <128925883.1247276789148.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/GPD-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475868#action_12475868 ] 

Ronald van Kuijk commented on GPD-35:
-------------------------------------

http://dev.eclipse.org/newslists/news.eclipse.modeling.gmf/msg17947.html

> enhancement drawing transitions
> -------------------------------
>
>                 Key: GPD-35
>                 URL: https://jira.jboss.org/jira/browse/GPD-35
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>            Reporter: 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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 11 09:19:29 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 11 Jul 2009 09:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14072601.1247318369510.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated JBAS-6185:
-------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1


> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Scott Marlow
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

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

        


From jira-events at lists.jboss.org  Sat Jul 11 09:19:29 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 11 Jul 2009 09:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <349737701.1247318369838.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved JBAS-6185.
--------------------------------

    Resolution: Done


added MBeanServerBuilderImpl + LazyMBeanServer to run.jar 

> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Scott Marlow
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

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

        


From jira-events at lists.jboss.org  Sat Jul 11 10:39:29 2009
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Sat, 11 Jul 2009 10:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-306) Variable Instances
 translation
 funcionality(From MessageValue to simple types like String,Integer,Long)
In-Reply-To: <2123265903.1246520763456.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <454961406.1247323169217.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/BPEL-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475883#action_12475883 ] 

Alejandro Guizar commented on BPEL-306:
---------------------------------------

Message variables are maps by definition. MessageValue is just a specialized map. It cannot be translated directly to a simple type because it may contain multiple values.

Other kinds of variables, those defined with simple or complex schema types, or elements, are represented as DOM elements. Of these, only simple types could be represented as plain strings. There is a good reason why they are not: being able to treat simple or complex schema types indistinctly. Anyhow, is getting strings from simple types what you are looking for?

> Variable Instances translation funcionality(From MessageValue to simple types like String,Integer,Long)
> -------------------------------------------------------------------------------------------------------
>
>                 Key: BPEL-306
>                 URL: https://jira.jboss.org/jira/browse/BPEL-306
>             Project: JBoss jBPM BPEL
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1.1
>         Environment: Jboss 4.2.3.GA
> JBPM-BPEL 1.1.1
>            Reporter: francesco dicarlo
>            Assignee: Alejandro Guizar
>
> Would be good to have a functionality (i.e. a Translator) to automatically translate VariableInstance that in JBPM-BPEL are of type MessageValue into the simple type that were defined in the workflow.
> The use of this code \\Map varsMap=instance.getContextInstance().getVariables();\\ returns a Map with key the name of the variable but with value a type MessageValue that can't be translated automatically for all the workflow because relies on workflow implementation and design.

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

        


From jira-events at lists.jboss.org  Sat Jul 11 12:47:40 2009
From: jira-events at lists.jboss.org (Gurkan Erdogdu (JIRA))
Date: Sat, 11 Jul 2009 12:47:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-112) Adding Partial
 Implementation for Specification Chapter11
Message-ID: <546837010.1247330860697.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Adding Partial Implementation for Specification Chapter11
---------------------------------------------------------

                 Key: JBJCA-112
                 URL: https://jira.jboss.org/jira/browse/JBJCA-112
             Project: JBoss JCA
          Issue Type: Patch
          Components: Core
            Reporter: Gurkan Erdogdu
            Assignee: Jesper Pedersen
         Attachments: CommonProject.diff, CoreProject.diff, CoreTest.diff

I have implemented some of checks that are defined in the specification Chapter 11.

3 different patches exist

1* CommonProject.diff --> Contains utility class.

2* CoreProject.diff --> Updating WorkWrapper and WorkManagerImpl to support WorkContextProvider

3* CoreTest.diff --> Updating tests for Chapter 11


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

        


From jira-events at lists.jboss.org  Sat Jul 11 12:47:40 2009
From: jira-events at lists.jboss.org (Gurkan Erdogdu (JIRA))
Date: Sat, 11 Jul 2009 12:47:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-112) Adding Partial
 Implementation for Specification Chapter11
In-Reply-To: <546837010.1247330860697.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <106220501.1247330860783.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gurkan Erdogdu updated JBJCA-112:
---------------------------------

    Attachment: CommonProject.diff


> Adding Partial Implementation for Specification Chapter11
> ---------------------------------------------------------
>
>                 Key: JBJCA-112
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-112
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Core
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>         Attachments: CommonProject.diff, CoreProject.diff, CoreTest.diff
>
>
> I have implemented some of checks that are defined in the specification Chapter 11.
> 3 different patches exist
> 1* CommonProject.diff --> Contains utility class.
> 2* CoreProject.diff --> Updating WorkWrapper and WorkManagerImpl to support WorkContextProvider
> 3* CoreTest.diff --> Updating tests for Chapter 11

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

        


From jira-events at lists.jboss.org  Sat Jul 11 12:47:40 2009
From: jira-events at lists.jboss.org (Gurkan Erdogdu (JIRA))
Date: Sat, 11 Jul 2009 12:47:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-112) Adding Partial
 Implementation for Specification Chapter11
In-Reply-To: <546837010.1247330860697.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1328590447.1247330860926.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gurkan Erdogdu updated JBJCA-112:
---------------------------------

    Attachment: CoreProject.diff


> Adding Partial Implementation for Specification Chapter11
> ---------------------------------------------------------
>
>                 Key: JBJCA-112
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-112
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Core
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>         Attachments: CommonProject.diff, CoreProject.diff, CoreTest.diff
>
>
> I have implemented some of checks that are defined in the specification Chapter 11.
> 3 different patches exist
> 1* CommonProject.diff --> Contains utility class.
> 2* CoreProject.diff --> Updating WorkWrapper and WorkManagerImpl to support WorkContextProvider
> 3* CoreTest.diff --> Updating tests for Chapter 11

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

        


From jira-events at lists.jboss.org  Sat Jul 11 12:47:41 2009
From: jira-events at lists.jboss.org (Gurkan Erdogdu (JIRA))
Date: Sat, 11 Jul 2009 12:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-112) Adding Partial
 Implementation for Specification Chapter11
In-Reply-To: <546837010.1247330860697.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1010085915.1247330861062.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gurkan Erdogdu updated JBJCA-112:
---------------------------------

    Attachment: CoreTest.diff


> Adding Partial Implementation for Specification Chapter11
> ---------------------------------------------------------
>
>                 Key: JBJCA-112
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-112
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Core
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>         Attachments: CommonProject.diff, CoreProject.diff, CoreTest.diff
>
>
> I have implemented some of checks that are defined in the specification Chapter 11.
> 3 different patches exist
> 1* CommonProject.diff --> Contains utility class.
> 2* CoreProject.diff --> Updating WorkWrapper and WorkManagerImpl to support WorkContextProvider
> 3* CoreTest.diff --> Updating tests for Chapter 11

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

        


From jira-events at lists.jboss.org  Sat Jul 11 16:21:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Sat, 11 Jul 2009 16:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7089) <h:column> level
 rendering is not working in JBOSS
In-Reply-To: <1328936593.1247148869241.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1476111412.1247343689206.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert resolved JBAS-7089.
--------------------------------

    Resolution: Rejected


> <h:column> level rendering is not working in JBOSS 
> ---------------------------------------------------
>
>                 Key: JBAS-7089
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7089
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: windows
>            Reporter: anil kumar
>            Assignee: Stan Silvert
>
> <h:column> level rendering is not working in JBOSS but works in Glassfish.
>    <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
>              <h:column>
>              <h:outputText  value="#{screenConfig.displayTitle}"  rendered="#{'5' eq '5'}"> </h:outputText>   
>               </h:column>  
>          </h:dataTable> 
> this is working perfectly.
> <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
>              <h:column  rendered="#{'5' eq '5'}"> >
>              <h:outputText  value="#{screenConfig.displayTitle}" </h:outputText>   
>               </h:column>  
>          </h:dataTable> 
> where as above one is not working. I really don't understand why this is not working in JBOSS.

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

        


From jira-events at lists.jboss.org  Sat Jul 11 17:27:29 2009
From: jira-events at lists.jboss.org (Jaroslaw Kijanowski (JIRA))
Date: Sat, 11 Jul 2009 17:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2205) smooks core not
 shipped with the bin distribution
Message-ID: <152122708.1247347649157.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

smooks core not shipped with the bin distribution
-------------------------------------------------

                 Key: JBRULES-2205
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2205
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.1.FINAL
            Reporter: Jaroslaw Kijanowski
            Assignee: Mark Proctor


milyn-smooks-javabean-1.1.jar is shipped, but milyn-smooks-core-1.1.2.jar is missing in the zip distribution.

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

        


From jira-events at lists.jboss.org  Sun Jul 12 23:36:29 2009
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 12 Jul 2009 23:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2130) DSL Bug while
 creating comparison combinations
In-Reply-To: <17065276.1245415796493.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1262856931.1247456189665.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Proctor updated JBRULES-2130:
----------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)
    Priority: Major  (was: Blocker)


> DSL Bug while creating comparison combinations
> ----------------------------------------------
>
>                 Key: JBRULES-2130
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2130
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>         Environment: I tried building the DSL using Guvnor
>            Reporter: Prem Stephen
>            Assignee: Edson Tirelli
>
> In http://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/docs/drools-expert/html_single/index.html#d0e5595, section 4.10.4 - I am expanding on the following syntax example for structuring combinations in the DSL.
> In my example, I have
> [when]There is a Contact with=Contact()
> [when]- age is less than {age}=age < {age}
> [when]- age is greater than {age}=age > {age}
> [when]- age is less than or equal to {age}=age <= {age}   <-------------------- this line does not work
> [when]- age is foo than or equal to {age}=age <= {age}
> and my rule is
> when
> 	There is a Contact with
> 	- age is foo than or equal to 35
> 	
> then
> 	Log : "Contact exists Test";
> Now, the line that does not work is because it shares the start "age is less than " with an earlier DSL.
> Replacing "less" with "foo" works for this reason.
> I think the parsing needs to be fixed to look at the whole sentence.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 04:07:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 13 Jul 2009 04:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-113) Support standard 303
 validation annotation
Message-ID: <713920493.1247472449189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Support standard 303 validation annotation
------------------------------------------

                 Key: JBJCA-113
                 URL: https://jira.jboss.org/jira/browse/JBJCA-113
             Project: JBoss JCA
          Issue Type: Task
          Components: Deployer
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha2


*) ra16standard303.rar (Valid (@NotNull) - must be deployed)

Create a resource adapter in deployer/test that uses standard 303 defined 
tags like @NotNull and @Min

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

        


From jira-events at lists.jboss.org  Mon Jul 13 04:09:40 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 13 Jul 2009 04:09:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-114) Support customer 303
 validation annotation
Message-ID: <940958141.1247472580910.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Support customer 303 validation annotation
------------------------------------------

                 Key: JBJCA-114
                 URL: https://jira.jboss.org/jira/browse/JBJCA-114
             Project: JBoss JCA
          Issue Type: Task
          Components: Deployer
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha2


*) ra16user303.rar (Valid (@FrenchZipcode) - must be deployed)

Create a resource adapter in deployer/test that uses custom defined tags - 
an example would be @FrenchZipcode from the 303 spec. The resource adapter 
must of course include the classes needed to make this happen

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

        


From jira-events at lists.jboss.org  Mon Jul 13 04:13:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 13 Jul 2009 04:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-116) Negative test for
 customer 303 validation annotation
Message-ID: <673733390.1247472809337.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Negative test for customer 303 validation annotation
----------------------------------------------------

                 Key: JBJCA-116
                 URL: https://jira.jboss.org/jira/browse/JBJCA-116
             Project: JBoss JCA
          Issue Type: Task
          Components: Deployer
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha2


ra16user303jbossra.rar (Invalid - must fail)

define in ra.xml and override in jboss-ra.xml, validate should be fail

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

        


From jira-events at lists.jboss.org  Mon Jul 13 04:13:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 13 Jul 2009 04:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-115) Negative test for
 standard 303 validation annotation
Message-ID: <1562454476.1247472809212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Negative test for standard 303 validation annotation
----------------------------------------------------

                 Key: JBJCA-115
                 URL: https://jira.jboss.org/jira/browse/JBJCA-115
             Project: JBoss JCA
          Issue Type: Task
          Components: Deployer
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha3


ra16standard303jbossra.rar (Invalid - must fail)

define in ra.xml and override in jboss-ra.xml, validate should be fail

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

        


From jira-events at lists.jboss.org  Mon Jul 13 07:12:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 13 Jul 2009 07:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1682) duplicate key
 value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1749881008.1247483549295.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1682.
-----------------------------------

    Resolution: Done


Done.

format now: (starting from highest bit)

First 10 bits - node id
Next 39 bits - 4th - 42nd bits of system time
Next 15 bits - rotating counter


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

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

        


From jira-events at lists.jboss.org  Mon Jul 13 07:12:29 2009
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Mon, 13 Jul 2009 07:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2206) exists Foo() does
 not fire if facts inserted before rule
Message-ID: <1053908145.1247483549402.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

exists Foo() does not fire if facts inserted before rule
--------------------------------------------------------

                 Key: JBRULES-2206
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2206
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core  (expert)
    Affects Versions: 5.0.1.FINAL
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor


Facts of some type Foo are inserted into a StatefulKnowledgeSession, then a rule with LHS exists Foo() is added and fireAllRules() is called, but the rule does not fire.

If the same is done with the FOP-equivalent rule containing CE not(not Foo()), the rule fires.



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

        


From jira-events at lists.jboss.org  Mon Jul 13 07:21:29 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 13 Jul 2009 07:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-214)
 SchemaBindingValidator: complex
 types with adapters should pass validation as simple types
Message-ID: <1988836401.1247484089266.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SchemaBindingValidator: complex types with adapters should pass validation as simple types
------------------------------------------------------------------------------------------

                 Key: JBXB-214
                 URL: https://jira.jboss.org/jira/browse/JBXB-214
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.2.Beta1
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: JBossXB-2.0.2.GA


At the moment the fact that the complex type has an adapter associated with it is ignored during validation. And comparison of such complex types to XSD simple types fails.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 07:21:29 2009
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Mon, 13 Jul 2009 07:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2206) exists Foo() does
 not fire if facts inserted before rule
In-Reply-To: <1053908145.1247483549402.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <672837023.1247484089204.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolfgang Laun updated JBRULES-2206:
-----------------------------------

    Attachment: RuleTester.java
                test1.drl
                test2.drl


> exists Foo() does not fire if facts inserted before rule
> --------------------------------------------------------
>
>                 Key: JBRULES-2206
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2206
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Wolfgang Laun
>            Assignee: Mark Proctor
>         Attachments: RuleTester.java, test1.drl, test2.drl
>
>
> Facts of some type Foo are inserted into a StatefulKnowledgeSession, then a rule with LHS exists Foo() is added and fireAllRules() is called, but the rule does not fire.
> If the same is done with the FOP-equivalent rule containing CE not(not Foo()), the rule fires.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 07:25:29 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 13 Jul 2009 07:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-214)
 SchemaBindingValidator: complex
 types with adapters should pass validation as simple types
In-Reply-To: <1988836401.1247484089266.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <65852508.1247484329333.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBXB-214.
----------------------------------

    Resolution: Done


Done.

> SchemaBindingValidator: complex types with adapters should pass validation as simple types
> ------------------------------------------------------------------------------------------
>
>                 Key: JBXB-214
>                 URL: https://jira.jboss.org/jira/browse/JBXB-214
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.2.Beta1
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossXB-2.0.2.GA
>
>
> At the moment the fact that the complex type has an adapter associated with it is ignored during validation. And comparison of such complex types to XSD simple types fails.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 07:27:43 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 13 Jul 2009 07:27:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1867) Track the
 upgrades during EJB3 plugin 1.0.11 release
In-Reply-To: <260824002.1247218949130.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1516304148.1247484463941.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1867.
------------------------------------

                  Resolution: Done
    Component Fix Version(s): jboss-ejb3-plugin:1.0.11


> Track the upgrades during EJB3 plugin 1.0.11 release
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1867
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1867
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: plugin
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> This JIRA will track the dependency upgrades during the release of EJB3 plugin 1.0.11

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

        


From jira-events at lists.jboss.org  Mon Jul 13 07:37:29 2009
From: jira-events at lists.jboss.org (Naresh Bhatia (JIRA))
Date: Mon, 13 Jul 2009 07:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <612775691.1247485049349.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Naresh Bhatia reopened JBMESSAGING-1677:
----------------------------------------



Corrected original issue with 1000 messages by connecting correctly to JCA connection factory. No the problem occurs when we hit 3000 messages on a Windows machine.

> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Clebert Suconic
>         Attachments: JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

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

        


From jira-events at lists.jboss.org  Mon Jul 13 07:37:29 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 13 Jul 2009 07:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-215) add JBossXml
 annotation to filter
 transient properties in classes on a package level
Message-ID: <241823731.1247485049245.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

add JBossXml annotation to filter transient properties in classes on a package level
------------------------------------------------------------------------------------

                 Key: JBXB-215
                 URL: https://jira.jboss.org/jira/browse/JBXB-215
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Feature Request
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: JBossXB-2.0.2.GA


The prototype has been committed and currently looks like this (excerpt from package-info.java)

@JBossXmlTransients({
   // mark specific property in the type as transient
   @JBossXmlTransient(type = JBossObject.class, properties={"classShortName"}),
   // not specifying properties will make them all transient in the type
   @JBossXmlTransient(type = Base.class)
})
package org.jboss.test.xb.builder.object.jbossxmltransient.support;

import org.jboss.util.JBossObject;
import org.jboss.xb.annotations.JBossXmlTransient;import org.jboss.xb.annotations.JBossXmlTransients;

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

        


From jira-events at lists.jboss.org  Mon Jul 13 07:39:29 2009
From: jira-events at lists.jboss.org (Naresh Bhatia (JIRA))
Date: Mon, 13 Jul 2009 07:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1309874794.1247485169254.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Naresh Bhatia updated JBMESSAGING-1677:
---------------------------------------

    Attachment: JmsTest-v2.zip


Attaching v2 of the code that demonstrates the issue with 3000 messages on a windows machine.

> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Clebert Suconic
>         Attachments: JmsTest-v2.zip, JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

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

        


From jira-events at lists.jboss.org  Mon Jul 13 07:46:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 13 Jul 2009 07:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1869) Upgrade
 jboss-ejb3-build dependency in testsuite to 1.0.5-SNAPSHOT
Message-ID: <1684396779.1247485589262.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade jboss-ejb3-build dependency in testsuite to 1.0.5-SNAPSHOT
------------------------------------------------------------------

                 Key: EJBTHREE-1869
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1869
             Project: EJB 3.0
          Issue Type: Task
          Components: testsuite
            Reporter: jaikiran pai
            Assignee: jaikiran pai


The jobs on slaves of mike are failing to resolve the 1.0.4-SNAPSHOT or 1.0.4 of jboss-ejb3-build for 2 reasons:

1) The 1.0.4-SNAPSHOT of jboss-ejb3-build is not available through the relative path
2) The Maven settings on slaves are not pointing to jboss repo.

As a workaround, upgrade the jboss-ejb3-build dependency in testsuite to 1.0.5-SNAPSHOT (so that it is resolved locally through relative path).


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

        


From jira-events at lists.jboss.org  Mon Jul 13 08:12:29 2009
From: jira-events at lists.jboss.org (Changalasetti Nagakiran (JIRA))
Date: Mon, 13 Jul 2009 08:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6442) Response truncated
 in the presence of special character
In-Reply-To: <31820059.1233348224581.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <55128503.1247487149359.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476002#action_12476002 ] 

Changalasetti Nagakiran commented on JBAS-6442:
-----------------------------------------------

Hi, we have similear kind of issues happening with our application. 
Currently our application is running on Oracle 10G server and planning to migrate to Jboss. In our JBOSS development envornment many pages were truncated bacause of special characters. 

when can we expect fix for this issue. or could you please provide us some alternative solution. 
Thanks.
-NK

> Response truncated in the presence of special character
> -------------------------------------------------------
>
>                 Key: JBAS-6442
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6442
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows XP, JDK 1.6.0_11
>            Reporter: Juan Manuel Medina Apodaca
>            Assignee: Remy Maucherat
>         Attachments: SpecialCharacter.txt
>
>
> When a servlet puts a session attribute containing a collection of strings, one of the strings contains a special character (for example: ...) and this string is displayed in a JSP, the resulting page is truncated before the special character.
> For example, in a servlet:
> ArrayList optionList = new ArrayList();
> ...
> optionList.add("Any string 1");
> optionList.add("Any string 2");
> optionList.add("Any string 3");
> optionList.add("Any string 4");
> optionList.add("A string with ... character");
> optionList.add("Any string 6");
> optionList.add("Any string 7");
> optionList.add("Any string 8");
> ...
> request.getSession(false).setAttribute("myList", optionList);
> In the JSP:
> 			               <c:forEach var="currentOption" items="${myList}">
> 			                  ${currentOption}
> 			                </c:forEach>
> The resulting page gets truncated before the 5th line.
> In JBoss 4.0.0 the page shows complete, with a ? sign in the place of the special character.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 09:06:42 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 13 Jul 2009 09:06:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-116) Negative test for
 custom 303 validation annotation
In-Reply-To: <673733390.1247472809337.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <71199135.1247490402166.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang updated JBJCA-116:
-----------------------------

    Summary: Negative test for custom 303 validation annotation  (was: Negative test for customer 303 validation annotation)


> Negative test for custom 303 validation annotation
> --------------------------------------------------
>
>                 Key: JBJCA-116
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-116
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> ra16user303jbossra.rar (Invalid - must fail)
> define in ra.xml and override in jboss-ra.xml, validate should be fail

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

        


From jira-events at lists.jboss.org  Mon Jul 13 09:06:42 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 13 Jul 2009 09:06:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-114) Support custom 303
 validation annotation
In-Reply-To: <940958141.1247472580910.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1217838932.1247490402065.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang updated JBJCA-114:
-----------------------------

    Summary: Support custom 303 validation annotation  (was: Support customer 303 validation annotation)


> Support custom 303 validation annotation
> ----------------------------------------
>
>                 Key: JBJCA-114
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-114
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> *) ra16user303.rar (Valid (@FrenchZipcode) - must be deployed)
> Create a resource adapter in deployer/test that uses custom defined tags - 
> an example would be @FrenchZipcode from the 303 spec. The resource adapter 
> must of course include the classes needed to make this happen

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

        


From jira-events at lists.jboss.org  Mon Jul 13 09:39:41 2009
From: jira-events at lists.jboss.org (Alfie Kirkpatrick (JIRA))
Date: Mon, 13 Jul 2009 09:39:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-356) Designer creates
 duplicate handler nodes under decision nodes
Message-ID: <2099402771.1247492381837.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Designer creates duplicate handler nodes under decision nodes
-------------------------------------------------------------

                 Key: GPD-356
                 URL: https://jira.jboss.org/jira/browse/GPD-356
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM jPDL Designer 4.0.0.GA
            Reporter: Alfie Kirkpatrick
            Assignee: Koen Aers
            Priority: Minor


When switching between text mode and graphical mode and saving the process definition a few times a large number of handler elements can build up under each decision node. This doesn't seem to affect the running of the process so is more an inconvenience than anything, but could cause confusion if the handler parameters are modified.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 09:41:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Mon, 13 Jul 2009 09:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7052) when invoked from
 remote client, 
 call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1346784883.1247492489680.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7052:
---------------------------------

    Assignee: Ian Springer  (was: Scott M Stark)


> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Ian Springer
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

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

        


From jira-events at lists.jboss.org  Mon Jul 13 09:41:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Mon, 13 Jul 2009 09:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7052) when invoked from
 remote
 client, call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1978474975.1247492489909.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476025#action_12476025 ] 

Charles Crouch commented on JBAS-7052:
--------------------------------------

Ian, can you retest this please.

> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Ian Springer
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

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

        


From jira-events at lists.jboss.org  Mon Jul 13 09:52:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Mon, 13 Jul 2009 09:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-205) Provide a way to
 handle exceptions while doing check complete
Message-ID: <1231079725.1247493149630.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Provide a way to handle exceptions while doing check complete
-------------------------------------------------------------

                 Key: JBDEPLOY-205
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-205
             Project: JBoss Deployers
          Issue Type: Feature Request
          Components: maindeployer
    Affects Versions: JBDEPLOY-2.0.8.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For:  JBDEPLOY-2.2.x


Allow for exception handling in Deployers::checkComplete.
Introducing new ExceptionHandler interface.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 09:54:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 09:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-226) Define a repeatable
 build for these plugins to be exported as a feature
In-Reply-To: <23044378.1216376452176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1325572540.1247493269168.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers closed GPD-226.
-------------------------

    Resolution: Done


> Define a repeatable build for these plugins to be exported as a feature
> -----------------------------------------------------------------------
>
>                 Key: GPD-226
>                 URL: https://jira.jboss.org/jira/browse/GPD-226
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>


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

        


From jira-events at lists.jboss.org  Mon Jul 13 09:56:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 09:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-351) Modify project and
 jpdl creation wizards to allow for jBPM 3 and jBPM 4 to coexist
In-Reply-To: <20923654.1243721096388.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <348484753.1247493389145.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-351.
---------------------------

    Resolution: Done


> Modify project and jpdl creation wizards to allow for jBPM 3 and jBPM 4 to coexist
> ----------------------------------------------------------------------------------
>
>                 Key: GPD-351
>                 URL: https://jira.jboss.org/jira/browse/GPD-351
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>


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

        


From jira-events at lists.jboss.org  Mon Jul 13 09:56:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 09:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-333) Ensure backwards
 compatibility between GPD 3.1.x and GPD 4.x
In-Reply-To: <25062383.1241703286559.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <266840403.1247493389223.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-333.
---------------------------

    Resolution: Done


> Ensure backwards compatibility between GPD 3.1.x and GPD 4.x
> ------------------------------------------------------------
>
>                 Key: GPD-333
>                 URL: https://jira.jboss.org/jira/browse/GPD-333
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>


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

        


From jira-events at lists.jboss.org  Mon Jul 13 09:58:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 09:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-307) make g the last
	attribute
In-Reply-To: <13029711.1238663482840.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1429182412.1247493509155.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-307:
--------------------------

    Component/s: jpdl


> make g the last attribute
> -------------------------
>
>                 Key: GPD-307
>                 URL: https://jira.jboss.org/jira/browse/GPD-307
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>
> koen, could you check if it is easy to make g the last attribute ?  currently it seems to be systematically the first attribute.
> <process name="EndState" xmlns="http://jbpm.org/4/jpdl">
>   <start g="16,96,48,48">
>      <transition to="get return code" name=""/>
>   </start>
>   <state g="96,94,110,52" name="get return code">
>     <transition g="150,63:-36,11" name="200" to="ok"/>
>     <transition g=":-16,-27" name="400" to="bad request"/>
>     <transition g="150,177:-33,-32" name="500" to="internal server error"/>
>   </state>
>   <end g="239,40,48,48" name="ok" state="completed"/>
>   <end-cancel g="239,97,48,48" name="bad request"/>
>   <end-error g="240,154,48,48" name="internal server error"/>
> </process>

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

        


From jira-events at lists.jboss.org  Mon Jul 13 10:00:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-308) prevent empty names
In-Reply-To: <7408830.1238663603004.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1750844506.1247493629200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-308:
--------------------------

    Component/s: jpdl


> prevent empty names
> -------------------
>
>                 Key: GPD-308
>                 URL: https://jira.jboss.org/jira/browse/GPD-308
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>
> in end state example, i see you generated an empty name.  that should be prevented if possible.  the fact that this still parses without exception is actually a bug.
> <process name="EndState" xmlns="http://jbpm.org/4/jpdl">
>   <start g="16,96,48,48">
>      <transition to="get return code" name=""/>
>   </start>
>   <state g="96,94,110,52" name="get return code">
>     <transition g="150,63:-36,11" name="200" to="ok"/>
>     <transition g=":-16,-27" name="400" to="bad request"/>
>     <transition g="150,177:-33,-32" name="500" to="internal server error"/>
>   </state>
>   <end g="239,40,48,48" name="ok" state="completed"/>
>   <end-cancel g="239,97,48,48" name="bad request"/>
>   <end-error g="240,154,48,48" name="internal server error"/>
> </process>

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

        


From jira-events at lists.jboss.org  Mon Jul 13 10:02:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-312) activation.jar missing
In-Reply-To: <12405483.1239581002554.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <509026117.1247493749242.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-312.
---------------------------

    Resolution: Done


This is actually a problem in the 3.2.6 release of the runtime. It has been fixed in the meantime on the runtime.

> activation.jar missing
> ----------------------
>
>                 Key: GPD-312
>                 URL: https://jira.jboss.org/jira/browse/GPD-312
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM jPDL Designer 3.1.7
>            Reporter: Mauricio Salatino
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 3.1.8
>
>
> activation.jar missing, just remove the line that includes this jar in the file: src\resources\gpd\vesrion.info.xml, because if not this jar is needed in eclipse.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 10:02:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-313) sample project not
 create the sample process
In-Reply-To: <28112889.1239581122418.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1303924967.1247493749408.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-313.
---------------------------

    Resolution: Done


This is actually a problem om the jBPM 3.2.6 runtime. It has been fixed in the meantime.

> sample project not create the sample process
> --------------------------------------------
>
>                 Key: GPD-313
>                 URL: https://jira.jboss.org/jira/browse/GPD-313
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM jPDL Designer 3.1.7
>            Reporter: Mauricio Salatino
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 3.1.8
>
>
> the test and the action handler is created but the process is not created. This makes the example incomplete.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 10:04:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-309) CDATA sections in
 custom elements
 of actions with config-type="bean" cause a NPE in the jBPM GPD.
In-Reply-To: <27833917.1239352042648.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1942054259.1247493869187.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-309:
--------------------------

    Component/s: jpdl


> CDATA sections in custom elements of actions with config-type="bean" cause a NPE in the jBPM GPD.
> -------------------------------------------------------------------------------------------------
>
>                 Key: GPD-309
>                 URL: https://jira.jboss.org/jira/browse/GPD-309
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM jPDL Designer 3.1.6
>         Environment: Eclipse 3.4.1
>            Reporter: Roman Heinz
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 3.1.8
>
>
> CDATA sections in custom elements of actions with config-type="bean" cause a NPE in the jBPM GPD.
> <?xml version="1.0" encoding="UTF-8"?>
> <process-definition 
>   xmlns="urn:jbpm.org:jpdl-3.2"
>   name="simple">
>    <start-state name="start">
>       <transition name="to_state" to="first">
>       </transition>
>    </start-state>
>    <state name="first">
>         <event type="node-enter">
>             <action class="foo.Bar" name="fooAction" config-type="bean">
>                 <rowdocid><![CDATA[ Test ]]></rowdocid>
>             </action>
>         </event>
>       <transition name="to_end" to="end">
>       </transition>
>    </state>
>    <end-state name="end"></end-state>
> </process-definition>
> Result:
> java.lang.NullPointerException
> 	at org.jbpm.gd.common.xml.GenericElementXmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.common.xml.GenericElementXmlAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.common.xml.GenericElementXmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ActionDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ActionDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.EventDomAdapter.doModelAdd(Unknown Source)
> ...

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

        


From jira-events at lists.jboss.org  Mon Jul 13 10:21:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-347) <timer> tag in
 <transition> removed
Message-ID: <623466674.1247494889135.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-347.
---------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.0.GA
       Resolution: Done


> <timer> tag in <transition> removed
> -----------------------------------
>
>                 Key: GPD-347
>                 URL: https://jira.jboss.org/jira/browse/GPD-347
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>            Reporter: Johan Kumps
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>
> Consider a state like this :
> <state g="297,164,80,40" name="wait-partner">
> 	<transition g="-33,-18" name="updateReceived" to="end"/>
> 	<transition g="-41,-18" name="timeout" to="escalate-to-bis">
> 		<timer duedate="10 minutes"/>
> 	</transition>
> </state>
> When changing the layout of the process definition in the diagram view, the <timer> node is removed by GPD.
> <state g="297,164,80,40" name="wait-partner">
> 	<transition g="-33,-18" name="updateReceived" to="end"/>
> 	<transition g="-41,-18" name="timeout" to="escalate-to-bis">
> 	</transition>
> </state>

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

        


From jira-events at lists.jboss.org  Mon Jul 13 10:25:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-344) Editing looses
 conditions assigned to transitions
In-Reply-To: <23880405.1243431145809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1577391470.1247495129191.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-344.
---------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.0.GA
       Resolution: Done


> Editing looses conditions assigned to transitions
> -------------------------------------------------
>
>                 Key: GPD-344
>                 URL: https://jira.jboss.org/jira/browse/GPD-344
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>         Environment: GPD from jbpm-4.0.0.Beta2
>            Reporter: Alexis Seigneurin
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>
> When you edit a process which has conditions attached to transitions, these conditions are lost if you edit using the graphical editor.
> I am using the DecisionConditions process taken from the documentation:
> <process name="DecisionConditions" >
>   <start>
>     <transition to="evaluate document" />
>   </start>
>   <decision name="evaluate document">
>     <transition to="submit document">
>       <condition expr="#{content=="good"}" />
>     </transition>
>     <transition to="try again">
>       <condition expr="#{content=="not so good"}" />
>     </transition>
>     <transition to="give up" />
>   </decision>
>   <state name="submit document" />
>   <state name="try again" />
>   <state name="give up" />
> </process>

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

        


From jira-events at lists.jboss.org  Mon Jul 13 10:25:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-337) image clipping
In-Reply-To: <22840615.1242894476675.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <566797339.1247495129261.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-337:
--------------------------

    Component/s: jpdl


> image clipping
> --------------
>
>                 Key: GPD-337
>                 URL: https://jira.jboss.org/jira/browse/GPD-337
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> the generated images are too large.  clipping them would be nice to have.  
> watch out with clipping the top left corner (i assume that is coordinates 0,0).  if you clip that while saving the image, then the coordinates in the process, used by the console might be affected.  
> while clipping the bottom right  corner should be possible without problem for the console.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 10:27:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-302) Generate Form Dialog
 is NOT auto-populated with controller variables or named transitions
In-Reply-To: <25947797.1235964418319.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1001795206.1247495249216.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-302:
--------------------------

    Component/s: jpdl


> Generate Form Dialog is NOT auto-populated with controller variables or named transitions
> -----------------------------------------------------------------------------------------
>
>                 Key: GPD-302
>                 URL: https://jira.jboss.org/jira/browse/GPD-302
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM jPDL Designer 3.1.6
>         Environment: Eclipse 3.1.4 w/ jBPM 3.3.1.GA w/ GPD 3.1.6
>            Reporter: Noah N. O'Consequence
>            Assignee: Koen Aers
>            Priority: Minor
>
> The launched dialog of a task's "Generate Form..." button is NOT automatically populated with the task's defined controller variables nor with buttons that correspond to the task's named transitions.  This issue significantly hinders the usefulness of the GPD.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 10:31:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 13 Jul 2009 10:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7052) when invoked from
 remote client, 
 call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1021536366.1247495489419.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer resolved JBAS-7052.
--------------------------------

    Resolution: Done


I tested last week - looks good now.


> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Ian Springer
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

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

        


From jira-events at lists.jboss.org  Mon Jul 13 10:31:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-336) image generation fails
In-Reply-To: <18908917.1242894356480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1482320652.1247495489544.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-336:
--------------------------

    Component/s: jpdl


> image generation fails
> ----------------------
>
>                 Key: GPD-336
>                 URL: https://jira.jboss.org/jira/browse/GPD-336
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> image generation seems to work for org.jbpm.examples.async.activity
> but it seems to fail for org.jbpm.examples.async.fork.  in that case I get an image with only a diagonal line.
> koen, do you get the same with that example ?

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

        


From jira-events at lists.jboss.org  Mon Jul 13 10:38:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 13 Jul 2009 10:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2206) exists Foo()
 does not fire if facts inserted before rule
In-Reply-To: <1053908145.1247483549402.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <84572679.1247495909383.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned JBRULES-2206:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)


> exists Foo() does not fire if facts inserted before rule
> --------------------------------------------------------
>
>                 Key: JBRULES-2206
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2206
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Wolfgang Laun
>            Assignee: Edson Tirelli
>         Attachments: RuleTester.java, test1.drl, test2.drl
>
>
> Facts of some type Foo are inserted into a StatefulKnowledgeSession, then a rule with LHS exists Foo() is added and fireAllRules() is called, but the rule does not fire.
> If the same is done with the FOP-equivalent rule containing CE not(not Foo()), the rule fires.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 10:38:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 13 Jul 2009 10:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2206) exists Foo()
 does not fire if facts inserted before rule
In-Reply-To: <1053908145.1247483549402.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1833795392.1247495909597.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476039#action_12476039 ] 

Edson Tirelli commented on JBRULES-2206:
----------------------------------------

exists() and not(not()) should generate the exact same result. I will investigate. Thanks.

> exists Foo() does not fire if facts inserted before rule
> --------------------------------------------------------
>
>                 Key: JBRULES-2206
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2206
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Wolfgang Laun
>            Assignee: Edson Tirelli
>         Attachments: RuleTester.java, test1.drl, test2.drl
>
>
> Facts of some type Foo are inserted into a StatefulKnowledgeSession, then a rule with LHS exists Foo() is added and fireAllRules() is called, but the rule does not fire.
> If the same is done with the FOP-equivalent rule containing CE not(not Foo()), the rule fires.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 10:50:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-339) pageflow designer
In-Reply-To: <18436103.1242895977551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <980136580.1247496629265.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-339:
--------------------------

    Component/s: seam


> pageflow designer
> -----------------
>
>                 Key: GPD-339
>                 URL: https://jira.jboss.org/jira/browse/GPD-339
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: seam
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.x
>
>
> new version of the pageflow designer

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

        


From jira-events at lists.jboss.org  Mon Jul 13 10:50:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 13 Jul 2009 10:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2130) DSL Bug while
 creating comparison combinations
In-Reply-To: <17065276.1245415796493.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <331442502.1247496629372.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2130.
----------------------------------

    Fix Version/s: 5.1.0.M1
       Resolution: Rejected


This is not a bug. It is designed to be this way to allow grammar sentences chaining:

http://downloads.jboss.com/drools/docs/5.0.1.26597.FINAL/drools-expert/html_single/index.html#d0e5515

"You can chain DSL expressions together on one line, as long as it is clear to the parser what the {tokens} are (otherwise you risk reading in too much text until the end of the line). The DSL expressions are processed according to the mapping file, top to bottom in order. "

So, in case you don't want to chain the result of a sentence into another sentence, always write your most specific sentences first in the grammar file.

> DSL Bug while creating comparison combinations
> ----------------------------------------------
>
>                 Key: JBRULES-2130
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2130
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>         Environment: I tried building the DSL using Guvnor
>            Reporter: Prem Stephen
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> In http://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/docs/drools-expert/html_single/index.html#d0e5595, section 4.10.4 - I am expanding on the following syntax example for structuring combinations in the DSL.
> In my example, I have
> [when]There is a Contact with=Contact()
> [when]- age is less than {age}=age < {age}
> [when]- age is greater than {age}=age > {age}
> [when]- age is less than or equal to {age}=age <= {age}   <-------------------- this line does not work
> [when]- age is foo than or equal to {age}=age <= {age}
> and my rule is
> when
> 	There is a Contact with
> 	- age is foo than or equal to 35
> 	
> then
> 	Log : "Contact exists Test";
> Now, the line that does not work is because it shares the start "age is less than " with an earlier DSL.
> Replacing "less" with "foo" works for this reason.
> I think the parsing needs to be fixed to look at the whole sentence.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 10:52:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Mon, 13 Jul 2009 10:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-205) Provide a way to
 handle exceptions while doing check complete
In-Reply-To: <1231079725.1247493149630.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <246540573.1247496749200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBDEPLOY-205.
----------------------------------

    Resolution: Done


> Provide a way to handle exceptions while doing check complete
> -------------------------------------------------------------
>
>                 Key: JBDEPLOY-205
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-205
>             Project: JBoss Deployers
>          Issue Type: Feature Request
>          Components: maindeployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For:  JBDEPLOY-2.2.x
>
>
> Allow for exception handling in Deployers::checkComplete.
> Introducing new ExceptionHandler interface.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 10:56:41 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 13 Jul 2009 10:56:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-216)
 SchemaBindingValidator: ordering inside choice shouldn't be required
Message-ID: <2050915512.1247497001857.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SchemaBindingValidator: ordering inside choice shouldn't be required
--------------------------------------------------------------------

                 Key: JBXB-216
                 URL: https://jira.jboss.org/jira/browse/JBXB-216
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.2.Beta1
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: JBossXB-2.0.2.GA


The validator currently checks the ordering of particles in choices.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 11:00:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-218) Create an online
 distribution for the designer
In-Reply-To: <243694.1215448946850.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1090871464.1247497229367.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-218.
---------------------------

    Resolution: Out of Date


> Create an online distribution for the designer
> ----------------------------------------------
>
>                 Key: GPD-218
>                 URL: https://jira.jboss.org/jira/browse/GPD-218
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>            Reporter: Thomas Diesler
>            Assignee: Koen Aers
>
> The designer should be installable from a remote site (i.e. an update url to the designer should be sufficient)
> http://subclipse.tigris.org/install.html
> http://m2eclipse.codehaus.org/

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

        


From jira-events at lists.jboss.org  Mon Jul 13 11:04:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-37) include snap to grid
In-Reply-To: <30030403.1168963978540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1487524475.1247497469350.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-37.
--------------------------

    Resolution: Out of Date
      Assignee: Koen Aers


> include snap to grid
> --------------------
>
>                 Key: GPD-37
>                 URL: https://jira.jboss.org/jira/browse/GPD-37
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>
> While designing processes, it would be a lot easier if there is some kind of 'snap to grid'. You can then have easier manual allignment etc. Besides that, the images look better
> - transitions should snap to the grid to
> - transitions should be perpendicular at least if there are more than three points in the line 

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

        


From jira-events at lists.jboss.org  Mon Jul 13 11:04:29 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 13 Jul 2009 11:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-216)
 SchemaBindingValidator: ordering inside choice shouldn't be required
In-Reply-To: <2050915512.1247497001857.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1202721619.1247497469448.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBXB-216.
----------------------------------

    Resolution: Done


Fixed.

> SchemaBindingValidator: ordering inside choice shouldn't be required
> --------------------------------------------------------------------
>
>                 Key: JBXB-216
>                 URL: https://jira.jboss.org/jira/browse/JBXB-216
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.2.Beta1
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossXB-2.0.2.GA
>
>
> The validator currently checks the ordering of particles in choices.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 11:10:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-352) unable to generate
 process image in jpdl4
In-Reply-To: <14071258.1244185257421.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <905124539.1247497829231.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-352.
---------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.0.beta2
       Resolution: Done


> unable to generate process image in jpdl4
> -----------------------------------------
>
>                 Key: GPD-352
>                 URL: https://jira.jboss.org/jira/browse/GPD-352
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM jPDL Designer 4.0.0.beta1
>         Environment: windows xp
>            Reporter: maruthi pramod
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.beta2
>
>
> Hi,
> I am new to jbpm and we started R & D no jbpm4 beta version currently.i have requirement that i need to show the user by highlight the active state of the process .i am using jpdl4 1.0.0 beta version. but am unable to view or generate the image for process definitions for the new process definations or the for the examples provide by jbpm 4 beta version. and one more thing that i also unable to see the process image in GWT-console also . please provide some help on this issue.
> Thanks & regards 
> maruthi

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

        


From jira-events at lists.jboss.org  Mon Jul 13 11:13:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-74) Add a server adaptor
 to enable starting and stopping the 'jbpm server'.
In-Reply-To: <15710853.1178575432195.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <657311620.1247498009573.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-74.
--------------------------

    Resolution: Won't Fix


> Add a server adaptor to enable starting and stopping the 'jbpm server'.
> -----------------------------------------------------------------------
>
>                 Key: GPD-74
>                 URL: https://jira.jboss.org/jira/browse/GPD-74
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>


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

        


From jira-events at lists.jboss.org  Mon Jul 13 11:17:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-357) Error while validating
 jPDL file: Problem class was moved from API
Message-ID: <985295068.1247498249570.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Error while validating jPDL file: Problem class was moved from API
------------------------------------------------------------------

                 Key: GPD-357
                 URL: https://jira.jboss.org/jira/browse/GPD-357
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM jPDL Designer 4.0.0.GA
            Reporter: Koen Aers
            Assignee: Koen Aers
             Fix For: jBPM jPDL Designer 4.1




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

        


From jira-events at lists.jboss.org  Mon Jul 13 11:22:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-356) Designer creates
 duplicate handler nodes under decision nodes
In-Reply-To: <2099402771.1247492381837.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2044991389.1247498549152.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-356:
--------------------------

    Fix Version/s: jBPM jPDL Designer 4.1


> Designer creates duplicate handler nodes under decision nodes
> -------------------------------------------------------------
>
>                 Key: GPD-356
>                 URL: https://jira.jboss.org/jira/browse/GPD-356
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM jPDL Designer 4.0.0.GA
>            Reporter: Alfie Kirkpatrick
>            Assignee: Koen Aers
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.1
>
>
> When switching between text mode and graphical mode and saving the process definition a few times a large number of handler elements can build up under each decision node. This doesn't seem to affect the running of the process so is more an inconvenience than anything, but could cause confusion if the handler parameters are modified.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 11:24:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-357) Error while validating
 jPDL file: Problem class was moved from API
In-Reply-To: <985295068.1247498249570.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <913107664.1247498669298.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-357:
--------------------------

    Component/s: jpdl


> Error while validating jPDL file: Problem class was moved from API
> ------------------------------------------------------------------
>
>                 Key: GPD-357
>                 URL: https://jira.jboss.org/jira/browse/GPD-357
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM jPDL Designer 4.0.0.GA
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.1
>
>


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

        


From jira-events at lists.jboss.org  Mon Jul 13 11:26:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (GPD-154) process image
 rendered incorrectly for large process definition
In-Reply-To: <2916967.1186754521287.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1610175395.1247498789400.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers reassigned GPD-154:
-----------------------------

    Assignee: Koen Aers  (was: Tom Baeyens)


> process image rendered incorrectly for large process definition
> ---------------------------------------------------------------
>
>                 Key: GPD-154
>                 URL: https://jira.jboss.org/jira/browse/GPD-154
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>         Environment: mac osx,  tomcat 5.0.28
>            Reporter: Ross McDonald
>            Assignee: Koen Aers
>            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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 11:26:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-207) For task
 creation/modification, 
 prepopulate form fields/buttons in 'Generate Task Form' from xhtml if file
 exists.
In-Reply-To: <24046624.1190992301165.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1172486335.1247498789669.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-207.
---------------------------

    Resolution: Won't Fix


> For task creation/modification, prepopulate form fields/buttons in 'Generate Task Form'  from xhtml if file exists.
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: GPD-207
>                 URL: https://jira.jboss.org/jira/browse/GPD-207
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>            Reporter: Chris Whalen
>            Assignee: Tom Baeyens
>


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

        


From jira-events at lists.jboss.org  Mon Jul 13 11:34:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-278) Security issue allows
 arbitrary java code to be deployed and executed
In-Reply-To: <28885895.1229329956636.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1644681387.1247499269388.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-278.
---------------------------

    Resolution: Rejected


As can be derived from the comments, this issue has nothing to do with the GPD. A sandbox system for the runtime is being put in place.

> Security issue allows arbitrary java code to be deployed and executed
> ---------------------------------------------------------------------
>
>                 Key: GPD-278
>                 URL: https://jira.jboss.org/jira/browse/GPD-278
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>            Reporter: Thomas Diesler
>            Assignee: Koen Aers
>            Priority: Critical
>
> The GPD circumvents the JBoss deployer architecture and hence allows arbitrary code to be executed on the AS

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

        


From jira-events at lists.jboss.org  Mon Jul 13 11:36:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-353) contribute xsd to xml
 catalog (xsd dependent on runtime)
In-Reply-To: <22572021.1244570156492.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <730805262.1247499389100.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-353:
--------------------------

    Fix Version/s: jBPM jPDL Designer 4.1
                       (was: jBPM jPDL Designer 4.x)


> contribute xsd to xml catalog (xsd dependent on runtime)
> --------------------------------------------------------
>
>                 Key: GPD-353
>                 URL: https://jira.jboss.org/jira/browse/GPD-353
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.1
>
>


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

        


From jira-events at lists.jboss.org  Mon Jul 13 11:38:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-358) Create jBPM Project
 Configuration Wizard
Message-ID: <497794165.1247499509147.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Create jBPM Project Configuration Wizard
----------------------------------------

                 Key: GPD-358
                 URL: https://jira.jboss.org/jira/browse/GPD-358
             Project: JBoss jBPM GPD
          Issue Type: Task
          Components: jpdl
            Reporter: Koen Aers
            Assignee: Koen Aers
             Fix For: jBPM jPDL Designer 4.1


This wizard can be launched from the project popup menu in the Java/J2EE/Resources perspective. It will import all the libraries from the currently configured runtime.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 12:40:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Mon, 13 Jul 2009 12:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7085) Replace ejb3 secured
 profile service facade with secured remoting proxy
In-Reply-To: <1810173299.1247085411421.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <81658550.1247503229600.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7085:
---------------------------------

    Labels: profileservice  (was: )


> Replace ejb3 secured profile service facade with secured remoting proxy
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7085
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7085
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService, Security
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Its been decided to limit the number of dependencies an admin client needs to communicate with a secured profile service. We need to drop the ejb3 facade and provide a secured remoting based proxy bound in global jndi and an unsecured, but security manager controlled unsecured proxy under the java: local jndi namespace.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 12:40:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Mon, 13 Jul 2009 12:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7081)
 ConcurrentModificationException
 when invoking 'stop' managed operation on Queue managed component
In-Reply-To: <1715358388.1246912672146.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2037280426.1247503229433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7081:
---------------------------------

    Labels: profileservice  (was: )


> ConcurrentModificationException when invoking 'stop' managed operation on Queue managed component
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7081
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7081
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Here's the stack trace:
> Exception when invoking stop(): java.lang.reflect.UndeclaredThrowableException: Failed to invoke method 'stop' on component 'jboss.messaging.destination:name=ex
> ,service=Queue' with parameters [].
> Exception in thread "Thread-28" java.lang.RuntimeException: javax.ejb.EJBException: java.util.ConcurrentModificationException
>         at test.Worker.run(Worker.java:102)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: javax.ejb.EJBException: java.util.ConcurrentModificationException
>         at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:77)
>         at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)
>         at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
>         at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
>         at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
>         at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
>         at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
>         at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.util.ConcurrentModificationException
>         at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
>         at java.util.HashMap$EntryIterator.next(HashMap.java:834)
>         at java.util.HashMap$EntryIterator.next(HashMap.java:832)
>         at org.jboss.util.TimedCachePolicy.getValidKeys(TimedCachePolicy.java:364)
>         at org.jboss.virtual.plugins.cache.IterableTimedVFSCache.findContext(IterableTimedVFSCache.java:65)
>         at org.jboss.virtual.plugins.cache.CombinedVFSCache.findContext(CombinedVFSCache.java:116)
>         at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:91)
>         at org.jboss.virtual.VFS.getRoot(VFS.java:200)
>         at org.jboss.profileservice.management.templates.JmsDestinationTemplate.applyTemplate(JmsDestinationTemplate.java:115)
>         at org.jboss.profileservice.management.AbstractTemplateCreator.applyTemplate(AbstractTemplateCreator.java:99)
>         at org.jboss.profileservice.management.ManagementViewImpl.applyTemplate(ManagementViewImpl.java:1362)
>         at sun.reflect.GeneratedMethodAccessor449.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
>         at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
>         at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:97)
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
>         at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$3.applyTemplate(AOPProxy$3.java)
>         at org.jboss.profileservice.ejb.SecureManagementView.applyTemplate(SecureManagementView.java:77)
>         at sun.reflect.GeneratedMethodAccessor446.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
>         at org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
>         at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
>         at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
>         at sun.reflect.GeneratedMethodAccessor386.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
>         at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_29585222.invoke(InvocationContextInterceptor_z_fillMet
> hod_29585222.java)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
>         at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_29585222.invoke(InvocationContextInterceptor_z_setup_295852
> 22.java)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
>         at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
>         at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
>         at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
>         at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
>         at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
>         at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$3.applyTemplate(AOPProxy$3.java)
>         at org.jboss.profileservice.ejb.SecureManagementView.applyTemplate(SecureManagementView.java:77)
>         at sun.reflect.GeneratedMethodAccessor446.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
>         at org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
>         at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
>         at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
>         at sun.reflect.GeneratedMethodAccessor386.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
>         at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_29585222.invoke(InvocationContextInterceptor_z_fillMet
> hod_29585222.java)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
>         at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_29585222.invoke(InvocationContextInterceptor_z_setup_295852
> 22.java)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
>         at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
>         at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
>         at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
>         at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
>         at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
>         at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.applyTemplate(Unknown Source)
>         at test.Worker.run(Worker.java:93)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.applyTemplate(Unknown Source)
>         at test.Worker.run(Worker.java:93)
>         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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 12:42:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Mon, 13 Jul 2009 12:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7072) Don't write a URL
 for host 0.0.0.0 in jnp-service.url
In-Reply-To: <15437469.1246547091499.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1234298219.1247503349124.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7072:
---------------------------------

    Labels: profileservice  (was: )


> Don't write a URL for host 0.0.0.0 in jnp-service.url
> -----------------------------------------------------
>
>                 Key: JBAS-7072
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7072
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services, Naming
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> See JOPR-254 for an explanation of the issue. This issue is to ensure NamingServiceURLWriter writes the correct URL.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 12:45:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Mon, 13 Jul 2009 12:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7050)
 "ClassNotFoundException:
 org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote
 calls to ManagementView.getTemplate()
Message-ID: <1161766619.1247503529754.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476068#action_12476068 ] 

Charles Crouch commented on JBAS-7050:
--------------------------------------

Lukas can you test please.

> "ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote calls to ManagementView.getTemplate()
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7050
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7050
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Lukas Krejci
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to create a datasource in AS5 using JON, the following exception occurs:
> java.lang.ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo                                                                                               
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)                                                                                            
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)                                                                                                 
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)                                                                                                                         
>         at java.lang.Class.forName0(Native Method)                                                                                                                                               
>         at java.lang.Class.forName(Class.java:247)                                                                                                                                               
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)                                                                   
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)                                                                                                               
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)                                                                                                                  
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)                                                                                                  
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)                                                                                                               
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)                                                                                                              
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)                                                                                                                 
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)                                                        
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)                                                                  
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)                                                                              
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)                                                                                     
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)                                                                        
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)                                                                             
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)                                                                                                 
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                                    
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                                     
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                            
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                          
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                        
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)                                                                                                                
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)                                                             
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> I was only able to find this class in jboss-embedded-all maven module.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 12:45:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Mon, 13 Jul 2009 12:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7050)
 "ClassNotFoundException:
 org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote
 calls to ManagementView.getTemplate()
Message-ID: <2017550790.1247503529435.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7050:
---------------------------------

    Assignee: Lukas Krejci  (was: Scott M Stark)


> "ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote calls to ManagementView.getTemplate()
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7050
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7050
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Lukas Krejci
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to create a datasource in AS5 using JON, the following exception occurs:
> java.lang.ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo                                                                                               
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)                                                                                            
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)                                                                                                 
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)                                                                                                                         
>         at java.lang.Class.forName0(Native Method)                                                                                                                                               
>         at java.lang.Class.forName(Class.java:247)                                                                                                                                               
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)                                                                   
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)                                                                                                               
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)                                                                                                                  
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)                                                                                                  
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)                                                                                                               
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)                                                                                                              
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)                                                                                                                 
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)                                                        
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)                                                                  
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)                                                                              
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)                                                                                     
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)                                                                        
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)                                                                             
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)                                                                                                 
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                                    
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                                     
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                            
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                          
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                        
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)                                                                                                                
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)                                                             
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> I was only able to find this class in jboss-embedded-all maven module.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 12:47:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Mon, 13 Jul 2009 12:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-7050)
 "ClassNotFoundException:
 org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote
 calls to ManagementView.getTemplate()
Message-ID: <1174532460.1247503649370.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch reopened JBAS-7050:
----------------------------------



> "ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote calls to ManagementView.getTemplate()
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7050
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7050
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Lukas Krejci
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to create a datasource in AS5 using JON, the following exception occurs:
> java.lang.ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo                                                                                               
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)                                                                                            
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)                                                                                                 
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)                                                                                                                         
>         at java.lang.Class.forName0(Native Method)                                                                                                                                               
>         at java.lang.Class.forName(Class.java:247)                                                                                                                                               
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)                                                                   
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)                                                                                                               
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)                                                                                                                  
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)                                                                                                  
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)                                                                                                               
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)                                                                                                              
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)                                                                                                                 
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)                                                        
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)                                                                  
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)                                                                              
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)                                                                                     
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)                                                                        
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)                                                                             
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)                                                                                                 
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                                    
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                                     
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                            
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                          
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                        
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)                                                                                                                
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)                                                             
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> I was only able to find this class in jboss-embedded-all maven module.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 14:38:29 2009
From: jira-events at lists.jboss.org (Gurkan Erdogdu (JIRA))
Date: Mon, 13 Jul 2009 14:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-112) Adding Partial
 Implementation for Specification Chapter11
In-Reply-To: <546837010.1247330860697.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1794605417.1247510309274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gurkan Erdogdu updated JBJCA-112:
---------------------------------

    Attachment: CommonProject.patch
                CoreProject.patch
                CoreProjectTest.patch


Re-attached after running checkstyle tool and update accordingly.

> Adding Partial Implementation for Specification Chapter11
> ---------------------------------------------------------
>
>                 Key: JBJCA-112
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-112
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Core
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>         Attachments: CommonProject.diff, CommonProject.patch, CoreProject.diff, CoreProject.patch, CoreProjectTest.patch, CoreTest.diff
>
>
> I have implemented some of checks that are defined in the specification Chapter 11.
> 3 different patches exist
> 1* CommonProject.diff --> Contains utility class.
> 2* CoreProject.diff --> Updating WorkWrapper and WorkManagerImpl to support WorkContextProvider
> 3* CoreTest.diff --> Updating tests for Chapter 11

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

        


From jira-events at lists.jboss.org  Mon Jul 13 15:19:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Mon, 13 Jul 2009 15:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <311041377.1247512769473.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch reopened JBAS-6185:
----------------------------------



Good stuff Scott
Can you just note down what tests you executed/added to the testsuite for this issue?
Thanks

> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Scott Marlow
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 15:37:41 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 13 Jul 2009 15:37:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6970)
 org.jboss.test.profileservice.test.ProfileServiceUnitTestCase failing with
 IBM JDK
In-Reply-To: <14973284.1243005236696.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <213677985.1247513861375.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-6970.
----------------------------------

    Resolution: Done


This is no longer reproducable running locally or as seen in the latest Hudson run:
http://hudson.qa.jboss.com/hudson/view/EAP-CI/job/JBoss-EAP-5.0.x-Testsuite-ibm16/lastBuild/testReport/org.jboss.test.profileservice.test/ProfileServiceUnitTestCase(profileservice)/

> org.jboss.test.profileservice.test.ProfileServiceUnitTestCase failing with IBM JDK
> ----------------------------------------------------------------------------------
>
>                 Key: JBAS-6970
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6970
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: javacore.20090522.171654.29389.0003.txt, profileservice-test.log
>
>
> The org.jboss.test.profileservice.test.ProfileServiceUnitTestCase testcase fails with the following error:
> Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit.
> junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit.
> In the test log you can see this:
> one-test:
>    [delete] Deleting: /home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/log/test.log
>     [junit] Running org.jboss.test.profileservice.test.ProfileServiceUnitTestCase
>     [junit] Unhandled exception
>     [junit] Type=Segmentation error vmState=0x00040000
>     [junit] J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
>     [junit] Handler1=F7F8961B Handler2=F7F4E2CC InaccessibleAddress=D51E5488
>     [junit] EDI=0A0D7E78 ESI=00000003 EAX=FFAEC4A4 EBX=0A02E818
>     [junit] ECX=FFAEC4A4 EDX=D51E547C
>     [junit] EIP=F7F867D3 ES=0000002B DS=0000002B ESP=FFAEC46C
>     [junit] EFlags=00210296 CS=FFAE0023 SS=0004002B EBP=FFAEC474
>     [junit] Module=/mnt/jqa/ibm-java2-i386-50/jre/bin/libj9vm23.so
>     [junit] Module_base_address=F7F63000
>     [junit] Target=2_30_20081126_26240_lHdSMr (Linux 2.6.18-92.1.22.el5)
>     [junit] CPU=x86 (8 logical CPUs) (0x1f75ed000 RAM)
>     [junit] JVMDUMP006I Processing Dump Event "gpf", detail "" - Please Wait.
>     [junit] JVMDUMP007I JVM Requesting System Dump using '/home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/core.20090522.170741.29133.0001.dmp'
>     [junit] JVMDUMP010I System Dump written to /home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/core.20090522.170741.29133.0001.dmp
>     [junit] JVMDUMP007I JVM Requesting Snap Dump using '/home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/Snap.20090522.170741.29133.0002.trc'
>     [junit] JVMDUMP010I Snap Dump written to /home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/Snap.20090522.170741.29133.0002.trc
>     [junit] JVMDUMP007I JVM Requesting Java Dump using '/home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/javacore.20090522.170741.29133.0003.txt'
>     [junit] JVMDUMP010I Java Dump written to /home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/javacore.20090522.170741.29133.0003.txt
>     [junit] JVMDUMP013I Processed Dump Event "gpf", detail "".
>     [junit] Running org.jboss.test.profileservice.test.ProfileServiceUnitTestCase
>     [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
>     [junit] Test org.jboss.test.profileservice.test.ProfileServiceUnitTestCase FAILED (crashed)

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

        


From jira-events at lists.jboss.org  Mon Jul 13 15:40:29 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 13 Jul 2009 15:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6936) Testsuite fails
 during
 tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
In-Reply-To: <368622.1242662765255.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1073615533.1247514029217.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6936:
---------------------------------


I'm going to exclude the org.jboss.test.deployers.seam.test.SeamBookingExampleUnitTestCase and
org.jboss.test.deployers.seam.test.SeamJpaExampleUnitTestCase so we can get in a full test run with IBM JDK 6. 
There are additional issues updating the examples to use 2.1.2.CR1 or higher which contains RF 3.3.0 and the resolution
to the issue noted above.

> Testsuite fails during tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6936
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6936
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: threadDump.html
>
>
> The AS fails to start for the second time during the tests-profileservice target of the testsuite. This is caused by the first instance not being properly shutdown by the following ant command: <server:stop name="profileservice"/>

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

        


From jira-events at lists.jboss.org  Mon Jul 13 15:42:41 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 13 Jul 2009 15:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6969)
 org.jboss.test.profileservice.override.test.JmsDestinationOverrideTestCase
 failing with IBM JDK
In-Reply-To: <24863112.1243004277549.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <759026936.1247514161308.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-6969.
----------------------------------

    Resolution: Done


This is no longer reproducable running the tests locally or as seen in the latest Hudson run:
http://hudson.qa.jboss.com/hudson/view/EAP-CI/job/JBoss-EAP-5.0.x-Testsuite-ibm16/lastBuild/testReport/org.jboss.test.profileservice.override.test/

> org.jboss.test.profileservice.override.test.JmsDestinationOverrideTestCase failing with IBM JDK
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6969
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6969
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: TEST-org.jboss.test.profileservice.override.test.JmsDestinationOverrideTestCase-profileservice.xml
>
>
> All the 3 tests of org.jboss.test.profileservice.override.test.JmsDestinationOverrideTestCase fail with this error message:
> org.jboss.jms.server.destination.QueueServiceMO
> java.lang.ClassNotFoundException: org.jboss.jms.server.destination.QueueServiceMO
> 	at java.lang.Class.forName(Class.java:163)
> 	at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1568)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1490)
> 	at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1457)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1312)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1932)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1856)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1743)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1932)
> ...

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

        


From jira-events at lists.jboss.org  Mon Jul 13 16:20:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 13 Jul 2009 16:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7095) HA Web Sessions via
 Database Persistence
Message-ID: <1302881808.1247516429179.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

HA Web Sessions via Database Persistence
----------------------------------------

                 Key: JBAS-7095
                 URL: https://jira.jboss.org/jira/browse/JBAS-7095
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Clustering, Web (Tomcat) service
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: JBossAS-5.2.0.Beta1


Occasionally we receive input from the JBoss AS user community that they'd like to see an option to use database persistence as a mechanism to make web sessions highly available. The basic use case we here for this is environments where sessions need to be available to AS instances located across a WAN. JBoss Cache/JGroups clusters can span a WAN but often users find it impractical to configure their cluster(s) in that way. However, their IT infrastructure already supports making RDBMS data accessible across the WAN. So, persisting sessions to the DB makes them available across the WAN.

This JIRA is to create a session Manager impl that satisfies this request. It will be based on the distributed session manager code that we use with JBoss Cache replication, but the implementation of the DistributedCacheManager SPI that manager uses will be replaced with a version the interacts with a RDMBS.

See http://www.jboss.org/community/wiki/HAWebSessionsviaDatabasePersistence for details.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 16:28:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 13 Jul 2009 16:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-112) Adding Partial
 Implementation for Specification Chapter11
In-Reply-To: <546837010.1247330860697.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <798181065.1247516909332.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-112.
-----------------------------------

    Fix Version/s: 1.0.0.Alpha2
       Resolution: Done


> Adding Partial Implementation for Specification Chapter11
> ---------------------------------------------------------
>
>                 Key: JBJCA-112
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-112
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Core
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>         Attachments: CommonProject.diff, CommonProject.patch, CoreProject.diff, CoreProject.patch, CoreProjectTest.patch, CoreTest.diff
>
>
> I have implemented some of checks that are defined in the specification Chapter 11.
> 3 different patches exist
> 1* CommonProject.diff --> Contains utility class.
> 2* CoreProject.diff --> Updating WorkWrapper and WorkManagerImpl to support WorkContextProvider
> 3* CoreTest.diff --> Updating tests for Chapter 11

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

        


From jira-events at lists.jboss.org  Mon Jul 13 16:44:29 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 13 Jul 2009 16:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <692918536.1247517869574.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476123#action_12476123 ] 

Scott Marlow commented on JBAS-6185:
------------------------------------

I did not add any tests to the testsuite for this issue.  My steps to test:

1.  Remove current server from jbossas/build/output/*

2.  cd jbossas dev folder

3.  Do a clean build
     ./build.sh clean

4.  Build the as
     ./build.sh

5.  Change into the generated server bin folder
     cd build/output/jboss-6.0.0.Alpha1/bin

6.  Append the following lines to run.conf (as mentioned in the documentation link above)
 JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote"
 JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"
 JAVA_OPTS="$JAVA_OPTS -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl"

7.  Start the as 
    ./run.sh

8.  After server starts, run jconsole (should be in jdk/bin folder)
    jconsole

9.  In the JConsole program, choose the just started as process from the "New Connection/Local Process" dialog and click the "connect" button.  

10.  Click on the MBeans tab, you should see the familar JBoss.* mbeans and the built in ones too (java.lang + com.sun).



> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Scott Marlow
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 17:59:29 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Mon, 13 Jul 2009 17:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7085) Replace ejb3
 secured profile service facade with secured remoting proxy
In-Reply-To: <1810173299.1247085411421.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <807244512.1247522369224.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-7085.
---------------------------------

    Resolution: Done


This has been done. Note that the profileservice-jboss-beans.xml ProxyFactory bean has a createEjb3Links property which links the remoting proxy bindings to the old ejb3 facade names:

        <!-- Create links from secured proxies back to old secured ejb3 facades -->
        <property name="createEjb3Links">true</property>


> Replace ejb3 secured profile service facade with secured remoting proxy
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7085
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7085
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService, Security
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Its been decided to limit the number of dependencies an admin client needs to communicate with a secured profile service. We need to drop the ejb3 facade and provide a secured remoting based proxy bound in global jndi and an unsecured, but security manager controlled unsecured proxy under the java: local jndi namespace.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 19:01:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 13 Jul 2009 19:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-7085) Replace ejb3
 secured profile service facade with secured remoting proxy
In-Reply-To: <1810173299.1247085411421.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <942506613.1247526089361.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer reopened JBAS-7085:
--------------------------------



Can you summarize what the JNDI binding names are for:

1) the remote AOP proxy(s)
2) the local java:* unsecured proxy

Also, can you confirm that authentication is enabled by default for the AOP proxy and also describe the configuration steps for turning authentication on and off for it?


> Replace ejb3 secured profile service facade with secured remoting proxy
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7085
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7085
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService, Security
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Its been decided to limit the number of dependencies an admin client needs to communicate with a secured profile service. We need to drop the ejb3 facade and provide a secured remoting based proxy bound in global jndi and an unsecured, but security manager controlled unsecured proxy under the java: local jndi namespace.

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

        


From jira-events at lists.jboss.org  Mon Jul 13 20:43:29 2009
From: jira-events at lists.jboss.org (Richard Taylor (JIRA))
Date: Mon, 13 Jul 2009 20:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7096) SLSB with dependency
 on
 HASingletonDeployer / Barrier results in error message on second node on
 startup
Message-ID: <1291600071.1247532209260.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SLSB with dependency on HASingletonDeployer / Barrier results in error message on second node on startup
--------------------------------------------------------------------------------------------------------

                 Key: JBAS-7096
                 URL: https://jira.jboss.org/jira/browse/JBAS-7096
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: JBossAS-5.1.0.GA
         Environment: RHEL 4 Update 7 (and OSX 10.5.7), Sun JRE 1.6.0_12, JBoss 5.1.0 - "all" configuration
            Reporter: Richard Taylor
            Assignee: Brian Stansberry
            Priority: Minor


Basic cluster, two JBoss 5.1.0 nodes, "all" configuration.   First node starts fine.  Second node starts, however at the end of starting, any SLSBs that depend on the barrier result in an error being logged at startup (on the second node). 

Example:
DEPLOYMENTS MISSING DEPENDENCIES:
  Deployment "jboss.j2ee:ear=app-ear.ear,jar=app-ejb.jar,name=BoardPollerMDB,service=EJB3" is missing the following dependencies:
    Dependency "<UNKNOWN jboss.j2ee:ear=app-ear.ear,jar=app-ejb.jar,name=BoardPollerMDB,service=EJB3>" (should be in state "Described", bu
t is actually in state "** UNRESOLVED Demands 'jboss.ha:service=HASingletonDeployer,type=Barrier' **")

DEPLOYMENTS IN ERROR:
  Deployment "<UNKNOWN jboss.j2ee:ear=app-ear.ear,jar=app-ejb.jar,name=BoardPollerMDB,service=EJB3>" is in error due to the following reas
on(s): ** UNRESOLVED Demands 'jboss.ha:service=HASingletonDeployer,type=Barrier' **

The SLSBs on node 2 do properly start in a failover scenario when node 1 goes down.  So functionally things seem OK.  However the error message is a little concerning and it leaves us wondering if there is more to the problem.



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

        


From jira-events at lists.jboss.org  Mon Jul 13 22:39:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 13 Jul 2009 22:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1683) Create a tag
 porting the fix for JBMESSAGING-1682 to JBM 1.4.0.SP3-CP08
Message-ID: <227653208.1247539169302.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Create a tag porting the fix for JBMESSAGING-1682 to JBM 1.4.0.SP3-CP08
-----------------------------------------------------------------------

                 Key: JBMESSAGING-1683
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1683
             Project: JBoss Messaging
          Issue Type: Task
          Components: Messaging Core
    Affects Versions: 1.4.0.SP3.CP08
            Reporter: Howard Gao
            Assignee: Howard Gao
            Priority: Critical




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

        


From jira-events at lists.jboss.org  Mon Jul 13 22:55:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 13 Jul 2009 22:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1614) Remove 256
 bridge limitation
In-Reply-To: <11637338.1241212966583.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2060242541.1247540129514.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476140#action_12476140 ] 

Howard Gao commented on JBMESSAGING-1614:
-----------------------------------------

Note:

Due to JBMESSAGING-1682, the limit of node ID has been changed to 1023.


> Remove 256 bridge limitation
> ----------------------------
>
>                 Key: JBMESSAGING-1614
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1614
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
>
>
> Currently JBoss Messaging limits bridges to 256 just like it does for cluster nodes because each bridge participant has to have a unique ServerPeerID (an 8-bit value).  However, users may want to bridge more than 256 servers to a single host.  Can this constraint be removed for bridges?

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

        


From jira-events at lists.jboss.org  Mon Jul 13 23:56:29 2009
From: jira-events at lists.jboss.org (Mikheil Kapanadze (JIRA))
Date: Mon, 13 Jul 2009 23:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-912) ejb-jar.xml
 injected EntityManger fails in @PostConstruct annotated methods
In-Reply-To: <3249388.1173877358210.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <288694785.1247543789195.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476143#action_12476143 ] 

Mikheil Kapanadze commented on EJBTHREE-912:
--------------------------------------------

Hello,

Is this bug still not fixed? I have the same problem in JBoss 4.2.3GA
JDK 1.6 on Windows XP

Entity Manager is injected as 

@PersistenceContext(unitName = "MyUnit", type = PersistenceContextType.EXTENDED)
private EntityManager entityManager;

The following statement fails in method, annotated by @PostConstruct:
Query query = entityManager.createQuery("some-query-here");

Here is the exception from JBoss log file:

07:48:15,187 ERROR [STDERR] java.lang.RuntimeException: java.lang.NullPointerException
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.interceptor.LifecycleInterceptorHandler.postConstruct(LifecycleInterceptorHandler.java:113)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.EJBContainer.invokePostConstruct(EJBContainer.java:623)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.AbstractPool.create(AbstractPool.java:131)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.InfinitePool.get(InfinitePool.java:49)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.ThreadlocalPool.create(ThreadlocalPool.java:50)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.ThreadlocalPool.get(ThreadlocalPool.java:90)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:315)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:320)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.remoting.IsLocalInterceptor.invokeLocal(IsLocalInterceptor.java:81)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:72)
07:48:15,187 ERROR [STDERR] 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulRemoteProxy.invoke(StatefulRemoteProxy.java:139)
07:48:15,187 ERROR [STDERR] 	at $Proxy94.getCustomer(Unknown Source)
07:48:15,187 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
07:48:15,187 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
07:48:15,187 ERROR [STDERR] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
07:48:15,187 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Method.java:597)
07:48:15,187 ERROR [STDERR] 	at javax.el.BeanELResolver.getValue(BeanELResolver.java:62)
07:48:15,187 ERROR [STDERR] 	at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
07:48:15,187 ERROR [STDERR] 	at com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:72)
07:48:15,187 ERROR [STDERR] 	at org.apache.el.parser.AstValue.getValue(AstValue.java:97)
07:48:15,187 ERROR [STDERR] 	at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
07:48:15,187 ERROR [STDERR] 	at com.sun.faces.application.ValueBindingValueExpressionAdapter.getValue(ValueBindingValueExpressionAdapter.java:113)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.bean.FacesBeanImpl.getProperty(FacesBeanImpl.java:66)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.ValueRenderer.getValue(ValueRenderer.java:83)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.ValueRenderer.getConvertedString(ValueRenderer.java:51)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.OutputTextRenderer.encodeAll(OutputTextRenderer.java:68)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:224)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:711)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.render.RenderUtils.encodeRecursive(RenderUtils.java:70)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:299)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:321)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer.renderContent(PanelPartialRootRenderer.java:64)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.BodyRenderer.renderContent(BodyRenderer.java:138)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer.encodeAll(PanelPartialRootRenderer.java:119)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.BodyRenderer.encodeAll(BodyRenderer.java:78)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:335)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.DocumentRenderer.encodeAll(DocumentRenderer.java:80)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:224)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:711)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.component.UIXComponentBase.__encodeRecursive(UIXComponentBase.java:1280)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeAll(UIXComponentBase.java:731)
07:48:15,187 ERROR [STDERR] 	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:942)
07:48:15,187 ERROR [STDERR] 	at com.sun.faces.application.ViewHandlerImpl.doRenderView(ViewHandlerImpl.java:271)
07:48:15,187 ERROR [STDERR] 	at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:202)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:182)
07:48:15,187 ERROR [STDERR] 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:109)
07:48:15,187 ERROR [STDERR] 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
07:48:15,187 ERROR [STDERR] 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
07:48:15,187 ERROR [STDERR] 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:250)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:207)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:161)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
07:48:15,187 ERROR [STDERR] 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
07:48:15,187 ERROR [STDERR] 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
07:48:15,187 ERROR [STDERR] 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
07:48:15,187 ERROR [STDERR] 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
07:48:15,187 ERROR [STDERR] 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
07:48:15,187 ERROR [STDERR] 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
07:48:15,187 ERROR [STDERR] 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
07:48:15,187 ERROR [STDERR] 	at java.lang.Thread.run(Thread.java:619)
07:48:15,187 ERROR [STDERR] Caused by: java.lang.NullPointerException
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.entity.ExtendedEntityManager.getPersistenceContext(ExtendedEntityManager.java:56)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.entity.ExtendedEntityManager.createQuery(ExtendedEntityManager.java:126)
07:48:15,187 ERROR [STDERR] 	at ge.ewallet.core.service.console.ConsoleManagerService.postConstruct(ConsoleManagerService.java:32)
07:48:15,187 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
07:48:15,187 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
07:48:15,187 ERROR [STDERR] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
07:48:15,187 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Method.java:597)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.interceptor.LifecycleInvocationContextImpl.proceed(LifecycleInvocationContextImpl.java:159)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.interceptor.LifecycleInterceptorHandler.postConstruct(LifecycleInterceptorHandler.java:109)
07:48:15,187 ERROR [STDERR] 	... 73 more

> ejb-jar.xml injected EntityManger fails in @PostConstruct annotated methods
> ---------------------------------------------------------------------------
>
>                 Key: EJBTHREE-912
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-912
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>         Environment: Identified on jboss-4.0.5.GA from jems installer 1.2.GA, still present in head from svn co http://anonsvn.jboss.org/repos/jbossas/branches/Branch_4_0/  as of 13th March 2007.  Tests run agains JDK 1.5 on Win XP (sp2)
>            Reporter: Andrew Redhead
>         Attachments: build-test.xml, resources-xmleminjection.zip, src-xmleminjection.zip, xmleminjection-pu-test.jar, xmleminjection-test.jar
>
>
> Using an ejb-jar.xml file to inject an EntityManger into an EJB3 stateless session bean succeeds for bean interface methods but fails for @PostConstruct methods.
> In both cases the reference to the EntityManager is non-null, however in the @PostConstruct method, accessing the EnityManger underlying delegate fails.
> The test cases provide both an "API" interface case (which passes) and an @PostConstruct case, which currently fails.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 02:40:29 2009
From: jira-events at lists.jboss.org (Alexander Marktl (JIRA))
Date: Tue, 14 Jul 2009 02:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1684) Message
 remain in the queue and do not get dispatched
Message-ID: <1603937672.1247553629290.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Message remain in the queue and do not get dispatched
-----------------------------------------------------

                 Key: JBMESSAGING-1684
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1684
             Project: JBoss Messaging
          Issue Type: Quality Risk
         Environment: SuSe Linux Enterprise Server 10, Java 1.5.0_11, AS 5 with JBoss Messaging - default installation
            Reporter: Alexander Marktl
            Assignee: Tim Fox
            Priority: Minor


I tried to create 10 queues and send 10.000 messages per queue from a single producer per queue to a single consumer per queue. Unfortunately  not all of the messages where delivered, some messages remain in the queues and wait for delivery. The JMX console for example states: 3 messages in the queue, 3 messages pending for delivery. But nothing happens. My receivers don't get these last messages. I don't know if this is a configuration issue or a bug. 

The queues are named: qname_0 ...qname_n





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

        


From jira-events at lists.jboss.org  Tue Jul 14 02:45:29 2009
From: jira-events at lists.jboss.org (Alexander Marktl (JIRA))
Date: Tue, 14 Jul 2009 02:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1684) Message
 remain in the queue and do not get dispatched
In-Reply-To: <1603937672.1247553629290.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2027671497.1247553929324.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Marktl updated JBMESSAGING-1684:
------------------------------------------

    Attachment: jms-provider-evaluation.zip


The zip file contains the eclipse project i use for evaluating jms providers.
To run the test use the classes: StartMultipleMessageListener and StartMultipleMessageProducers which can be found in the ssi/jms/simple/general/starttests package. 
For the field companyname use "JBOSS" all in uppercase.
Run the MessageListeners first and then start up the Message Producers.

> Message remain in the queue and do not get dispatched
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1684
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1684
>             Project: JBoss Messaging
>          Issue Type: Quality Risk
>         Environment: SuSe Linux Enterprise Server 10, Java 1.5.0_11, AS 5 with JBoss Messaging - default installation
>            Reporter: Alexander Marktl
>            Assignee: Tim Fox
>            Priority: Minor
>         Attachments: jms-provider-evaluation.zip
>
>
> I tried to create 10 queues and send 10.000 messages per queue from a single producer per queue to a single consumer per queue. Unfortunately  not all of the messages where delivered, some messages remain in the queues and wait for delivery. The JMX console for example states: 3 messages in the queue, 3 messages pending for delivery. But nothing happens. My receivers don't get these last messages. I don't know if this is a configuration issue or a bug. 
> The queues are named: qname_0 ...qname_n

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

        


From jira-events at lists.jboss.org  Tue Jul 14 03:10:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 14 Jul 2009 03:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1684) Message
 remain in the queue and do not get dispatched
In-Reply-To: <1603937672.1247553629290.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1433895747.1247555429858.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1684:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> Message remain in the queue and do not get dispatched
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1684
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1684
>             Project: JBoss Messaging
>          Issue Type: Quality Risk
>         Environment: SuSe Linux Enterprise Server 10, Java 1.5.0_11, AS 5 with JBoss Messaging - default installation
>            Reporter: Alexander Marktl
>            Assignee: Howard Gao
>            Priority: Minor
>         Attachments: jms-provider-evaluation.zip
>
>
> I tried to create 10 queues and send 10.000 messages per queue from a single producer per queue to a single consumer per queue. Unfortunately  not all of the messages where delivered, some messages remain in the queues and wait for delivery. The JMX console for example states: 3 messages in the queue, 3 messages pending for delivery. But nothing happens. My receivers don't get these last messages. I don't know if this is a configuration issue or a bug. 
> The queues are named: qname_0 ...qname_n

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

        


From jira-events at lists.jboss.org  Tue Jul 14 03:47:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 14 Jul 2009 03:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1683) Create a tag
 porting the fix for JBMESSAGING-1682 to JBM 1.4.0.SP3-CP08
In-Reply-To: <227653208.1247539169302.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1524598028.1247557649284.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1683.
-----------------------------------

    Resolution: Done


Done. tag created:

https://svn.jboss.org/repos/messaging/tags/JBossMessaging_1_4_0_SP3_CP08.patch01/

> Create a tag porting the fix for JBMESSAGING-1682 to JBM 1.4.0.SP3-CP08
> -----------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1683
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1683
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>            Priority: Critical
>


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

        


From jira-events at lists.jboss.org  Tue Jul 14 04:50:43 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 14 Jul 2009 04:50:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1831) Clean up
	dependency chains
In-Reply-To: <13433231.1242136368008.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <93276200.1247561443067.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1831:
-----------------------------------

    Fix Version/s: 1.1.10
                       (was: 1.1.9)


> Clean up dependency chains
> --------------------------
>
>                 Key: EJBTHREE-1831
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1831
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: as-int, ejb3
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.10
>
>
> The true order should be:
> jboss-ejb3 > as-int > AS
> jboss-ejb3 > Plugin
> Whereas now as-int goes into Plugin.  Also endpoint-deployer should be included in as-int and Plugin, and not explicitly declared by AS itself.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 04:54:41 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 14 Jul 2009 04:54:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1814)
 NoPassivationCache does not obey maxSize
In-Reply-To: <17499438.1240909569920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <824983734.1247561681423.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1814:
-----------------------------------

    Fix Version/s: 1.1.10
                       (was: 1.1.9)


> NoPassivationCache does not obey maxSize
> ----------------------------------------
>
>                 Key: EJBTHREE-1814
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1814
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: cache
>            Reporter: Carlo de Wolf
>             Fix For: 1.1.10
>
>


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

        


From jira-events at lists.jboss.org  Tue Jul 14 06:26:29 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 14 Jul 2009 06:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1814)
 NoPassivationCache does not obey maxSize
In-Reply-To: <17499438.1240909569920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1129313111.1247567189485.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf updated EJBTHREE-1814:
------------------------------------

    Fix Version/s:     (was: 1.1.10)


> NoPassivationCache does not obey maxSize
> ----------------------------------------
>
>                 Key: EJBTHREE-1814
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1814
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: cache
>            Reporter: Carlo de Wolf
>


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

        


From jira-events at lists.jboss.org  Tue Jul 14 06:35:30 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ville_Skytt=C3=A4_=28JIRA=29?=)
Date: Tue, 14 Jul 2009 06:35:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1701)
 getTimerService() can no longer be called in @Service start()
In-Reply-To: <2268578.1233053864441.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <825161588.1247567730223.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476173#action_12476173 ] 

Ville Skytt? commented on EJBTHREE-1701:
----------------------------------------

Another forum reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=158378

Any progress on this?

> getTimerService() can no longer be called in @Service start()
> -------------------------------------------------------------
>
>                 Key: EJBTHREE-1701
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1701
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: trunk
>         Environment: 5.0.0.GA
>            Reporter: Matt C
>            Assignee: Andrew Lee Rubinger
>         Attachments: EJBTHREE-1701_testcase_v1.patch, EJBTHREE-1701_testcase_v2.patch
>
>
> Calling getTimerService() is no longer allowed from the lifecycle methods of @Service.
> Exception java.lang.IllegalStateException: getTimerService() not allowed during injection (EJB3 4.5.2).
> This occurs in the start() method of a @Service bean. The effect is to disallow setup of application-wide timers.
> This action is erroneously disallowed based on Table 2 in the EJB3 specification, section 4.5.2 (IMHO).
> Service lifecycle methods are not dependency injection methods, furthermore @Service beans are outside of the EJB3 specification.
> Lifecycle methods of a service should probably be considered business methods, not DI in the context of Table 2. They are in the @Management business interface.
> There is no workaround yet for this backwards incompatible change which breaks apps that set up application-wide timers from Services when they are migrated to 5.0.0.GA. This used to work in 4.2.x.

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

       



From jira-events at lists.jboss.org  Tue Jul 14 06:37:29 2009
From: jira-events at lists.jboss.org (francesco dicarlo (JIRA))
Date: Tue, 14 Jul 2009 06:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-306) Variable Instances
 translation
 funcionality(From MessageValue to simple types like String,Integer,Long)
In-Reply-To: <2123265903.1246520763456.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <73597139.1247567849283.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/BPEL-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476175#action_12476175 ] 

francesco dicarlo commented on BPEL-306:
----------------------------------------

yes it is. 

> Variable Instances translation funcionality(From MessageValue to simple types like String,Integer,Long)
> -------------------------------------------------------------------------------------------------------
>
>                 Key: BPEL-306
>                 URL: https://jira.jboss.org/jira/browse/BPEL-306
>             Project: JBoss jBPM BPEL
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1.1
>         Environment: Jboss 4.2.3.GA
> JBPM-BPEL 1.1.1
>            Reporter: francesco dicarlo
>            Assignee: Alejandro Guizar
>
> Would be good to have a functionality (i.e. a Translator) to automatically translate VariableInstance that in JBPM-BPEL are of type MessageValue into the simple type that were defined in the workflow.
> The use of this code \\Map varsMap=instance.getContextInstance().getVariables();\\ returns a Map with key the name of the variable but with value a type MessageValue that can't be translated automatically for all the workflow because relies on workflow implementation and design.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 07:44:29 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Tue, 14 Jul 2009 07:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
Message-ID: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

jboss messaging / memory leak on session.rollback() operation
-------------------------------------------------------------

                 Key: JBMESSAGING-1685
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.3.GA
         Environment: Windows Server 2003/SP2
            Reporter: Martin Gysel
            Assignee: Tim Fox
             Fix For: 1.4.3.GA


we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.

the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
- close session/connection after so many rollback() operation, e.g. 100
- close session/connection after all messages have been received (and removed)
- clustered vs. not clustered makes no difference
- hypersonic vs. db2 makes no difference
- adding a DLQ makes no difference
- DeliveryMode.NON_PERSISTENT makes no difference

the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
we do not use XA.

thanks for your help.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 07:46:30 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Jul 2009 07:46:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1616) Classpath
 issue with file version.properties
In-Reply-To: <7671035.1241530427144.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1322292433.1247571990034.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1616:
---------------------------------

    Fix Version/s: 2.0.0


> Classpath issue with file version.properties
> --------------------------------------------
>
>                 Key: JBMESSAGING-1616
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1616
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Alpha
>            Reporter: Markus Probst
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> In class org.jboss.messaging.util.VersionLoader the static method "load" throws a NumberFormatException while trying to read properties from file version.properties, if several files with this name are situated in current classpath and the "wrong" one is picked up:
> "
> java.lang.NumberFormatException: null
> at java.lang.Integer.parseInt(Integer.java:415)
> at java.lang.Integer.valueOf(Integer.java:553)
> at org.jboss.messaging.util.VersionLoader.load(VersionLoader.java:50)
> at org.jboss.messaging.core.client.impl.ClientConnectionFactoryImpl.createConnection(ClientConnectionFactoryImpl.java:135)
> at org.jboss.messaging.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:255)
> at org.jboss.messaging.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:134)
> ...
> "
> It is very likely that more than one library/artifacts contains a file called "version.properties", so I think the right way should be to rename this file to a more JBoss Messaging specific one.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 08:32:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Tue, 14 Jul 2009 08:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <2079693420.1247574749324.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476185#action_12476185 ] 

Ales Justin commented on JBAS-7032:
-----------------------------------

Stan, can you attach this "fixed" ear.
Or how do I reproduce this?

I'm looking into WBINT-16, which is what is mentioned at the end of WBINT-15 discussion.

Do we have any clue why admin-console uses that WBPhaseListener?
As WebBeansUrlIntegrationDeployer is pretty simple and shouldn't add faces/ to cp.

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 09:13:30 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Tue, 14 Jul 2009 09:13:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1013727811.1247577210101.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch resolved JBAS-6185.
----------------------------------

    Resolution: Done


>From ScottM...

> a) just using the platform mbean server stills works (no jconsole)
>    

This works

> b) just using com.sun.remoting still works (jconsole, but no java mbean in the jmxconsole)
>    

This also works


> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Scott Marlow
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 09:15:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Tue, 14 Jul 2009 09:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBAS-7097) Stack overflow error
 when establishing secured connection to Profile Service
Message-ID: <1644879891.1247577329470.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukas Krejci moved JOPR-286 to JBAS-7097:
-----------------------------------------

        Project: JBoss Application Server  (was: Jopr)
            Key: JBAS-7097  (was: JOPR-286)
    Component/s: ProfileService
                     (was: Plugin - JBoss AS 5)


> Stack overflow error when establishing secured connection to Profile Service
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7097
>             Project: JBoss Application Server
>          Issue Type: Bug
>          Components: ProfileService
>         Environment: Jopr rev902, AS5 EAP rev91190
>            Reporter: Lukas Krejci
>            Priority: Blocker
>
> The stack overflow occurs in AbstractProfileServiceConnection.init() after the connection has been established.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
>         at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
> Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
>         at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
>         at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
>         ... 12 more                                                                                                                                                                       
> Caused by: java.lang.StackOverflowError                                                                                                                                                   
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
> ....                                                                           
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
>         ... 18 more                                                                                                                                                                       

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

        


From jira-events at lists.jboss.org  Tue Jul 14 09:17:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Jul 2009 09:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1628) lack of
 support for java 1.4 clients
In-Reply-To: <11536840.1242421546884.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1123361493.1247577449298.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476201#action_12476201 ] 

Tim Fox commented on JBMESSAGING-1628:
--------------------------------------

Sorry! No plans to support 1.4 clients. We just don't have enough interest in this to make it worthwhile. 

> lack of support for java 1.4 clients
> ------------------------------------
>
>                 Key: JBMESSAGING-1628
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1628
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Remoting
>    Affects Versions: 1.4.3.GA
>         Environment: windows xp, j2sdk1.4.2_13 and jdk1.6.0_05
>            Reporter: alexguev
>            Assignee: Tim Fox
>
> The messaging clients libraries are java 5 bytecode, which prevents the use of jboss messaging from java 1.4 code. I made an attempt to retro-translate the messaging client libraries using the retrotranslator project with limited success. Basically, things went pretty well up to the point where the java vm complained with this error:
> java.lang.ClassFormatError: org/jboss/jms/client/delegate/ClientConnectionFactoryDelegate (Invalid start_pc/length in local var table)
> I was wondering if there are any plans for jboss-messaging to support java 1.4 clients ? also, should I try using the jboss-retro project instead ?
> thanks in advance.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 09:17:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Jul 2009 09:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1628) lack of
 support for java 1.4 clients
In-Reply-To: <11536840.1242421546884.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <113494244.1247577449416.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox closed JBMESSAGING-1628.
--------------------------------

    Resolution: Rejected


> lack of support for java 1.4 clients
> ------------------------------------
>
>                 Key: JBMESSAGING-1628
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1628
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Remoting
>    Affects Versions: 1.4.3.GA
>         Environment: windows xp, j2sdk1.4.2_13 and jdk1.6.0_05
>            Reporter: alexguev
>            Assignee: Tim Fox
>
> The messaging clients libraries are java 5 bytecode, which prevents the use of jboss messaging from java 1.4 code. I made an attempt to retro-translate the messaging client libraries using the retrotranslator project with limited success. Basically, things went pretty well up to the point where the java vm complained with this error:
> java.lang.ClassFormatError: org/jboss/jms/client/delegate/ClientConnectionFactoryDelegate (Invalid start_pc/length in local var table)
> I was wondering if there are any plans for jboss-messaging to support java 1.4 clients ? also, should I try using the jboss-retro project instead ?
> thanks in advance.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 09:19:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Jul 2009 09:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1621333158.1247577569212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1677:
---------------------------------

    Fix Version/s: 2.0.0


> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>         Attachments: JmsTest-v2.zip, JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

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

        


From jira-events at lists.jboss.org  Tue Jul 14 09:21:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Tue, 14 Jul 2009 09:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7097) Stack overflow
 error when establishing secured connection to Profile Service
Message-ID: <319874981.1247577689597.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476203#action_12476203 ] 

Lukas Krejci commented on JBAS-7097:
------------------------------------

This exception occurs during DeploymentManager.loadProfile() method wrapped in a dynamic proxy with http://anonsvn.jboss.org/repos/jopr/trunk/modules/plugins/jboss-as-5/src/main/java/org/rhq/plugins/jbossas5/connection/JaasAuthenticationInvocationHandler.java as a handler.

> Stack overflow error when establishing secured connection to Profile Service
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7097
>             Project: JBoss Application Server
>          Issue Type: Bug
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Jopr rev902, AS5 EAP rev91190
>            Reporter: Lukas Krejci
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The stack overflow occurs in AbstractProfileServiceConnection.init() after the connection has been established.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
>         at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
> Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
>         at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
>         at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
>         ... 12 more                                                                                                                                                                       
> Caused by: java.lang.StackOverflowError                                                                                                                                                   
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
> ....                                                                           
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
>         ... 18 more                                                                                                                                                                       

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

        


From jira-events at lists.jboss.org  Tue Jul 14 09:21:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Tue, 14 Jul 2009 09:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7097) Stack overflow
 error when establishing secured connection to Profile Service
Message-ID: <982882790.1247577689804.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukas Krejci reassigned JBAS-7097:
----------------------------------

    Assignee: Scott M Stark


> Stack overflow error when establishing secured connection to Profile Service
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7097
>             Project: JBoss Application Server
>          Issue Type: Bug
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Jopr rev902, AS5 EAP rev91190
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The stack overflow occurs in AbstractProfileServiceConnection.init() after the connection has been established.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
>         at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
> Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
>         at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
>         at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
>         ... 12 more                                                                                                                                                                       
> Caused by: java.lang.StackOverflowError                                                                                                                                                   
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
> ....                                                                           
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
>         ... 18 more                                                                                                                                                                       

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

        


From jira-events at lists.jboss.org  Tue Jul 14 09:21:30 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Tue, 14 Jul 2009 09:21:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7097) Stack overflow error
 when establishing secured connection to Profile Service
Message-ID: <1362091935.1247577690327.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7097:
-------------------------------

        Fix Version/s: JBossAS-5.2.0.Beta1
    Affects Version/s: JBossAS-5.1.0.GA
               Labels: EmbJopr1_3 profileservice  (was: )


> Stack overflow error when establishing secured connection to Profile Service
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7097
>             Project: JBoss Application Server
>          Issue Type: Bug
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Jopr rev902, AS5 EAP rev91190
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The stack overflow occurs in AbstractProfileServiceConnection.init() after the connection has been established.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
>         at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
> Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
>         at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
>         at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
>         ... 12 more                                                                                                                                                                       
> Caused by: java.lang.StackOverflowError                                                                                                                                                   
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
> ....                                                                           
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
>         ... 18 more                                                                                                                                                                       

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

        


From jira-events at lists.jboss.org  Tue Jul 14 09:27:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Tue, 14 Jul 2009 09:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7097) Stack overflow error
 when establishing secured connection to Profile Service
Message-ID: <471920220.1247578049317.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukas Krejci updated JBAS-7097:
-------------------------------

    Description: 
The stack overflow occurs in Jopr AS5 plugin AbstractProfileServiceConnection.init() after the connection has been established.

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
        at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
        at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
        at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
        at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
        at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
        at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
        at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
        at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
        at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
        at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
        at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
        at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
        at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
        ... 12 more                                                                                                                                                                       
Caused by: java.lang.StackOverflowError                                                                                                                                                   
        at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
        at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
        at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
        at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
        at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
        at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
        at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
....                                                                           
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
        at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
        at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
        at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
        at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
        ... 18 more                                                                                                                                                                       

  was:
The stack overflow occurs in AbstractProfileServiceConnection.init() after the connection has been established.

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
        at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
        at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
        at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
        at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
        at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
        at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
        at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
        at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
        at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
        at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
        at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
        at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
        at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
        ... 12 more                                                                                                                                                                       
Caused by: java.lang.StackOverflowError                                                                                                                                                   
        at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
        at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
        at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
        at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
        at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
        at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
        at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
....                                                                           
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
        at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
        at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
        at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
        at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
        ... 18 more                                                                                                                                                                       



> Stack overflow error when establishing secured connection to Profile Service
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7097
>             Project: JBoss Application Server
>          Issue Type: Bug
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Jopr rev902, AS5 EAP rev91190
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The stack overflow occurs in Jopr AS5 plugin AbstractProfileServiceConnection.init() after the connection has been established.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
>         at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
> Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
>         at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
>         at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
>         ... 12 more                                                                                                                                                                       
> Caused by: java.lang.StackOverflowError                                                                                                                                                   
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
> ....                                                                           
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
>         ... 18 more                                                                                                                                                                       

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

        


From jira-events at lists.jboss.org  Tue Jul 14 09:31:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Tue, 14 Jul 2009 09:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7076) DeploymentTemplate
 temp file url is not escaped properly
In-Reply-To: <1147631592.1246738311392.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1294125563.1247578289565.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7076:
---------------------------------

    Labels: profileservice  (was: )


> DeploymentTemplate temp file url is not escaped properly
> --------------------------------------------------------
>
>                 Key: JBAS-7076
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7076
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>
> The DsDataSourceTemplate applyTemplate method is creating a temp file, but somewhere the file url is not being properly escaped (at least on mac os x), as a temp file name of
> /var/folders/jY/jY1BDqLkHKO+a4nm+GooZE+++TI/-Tmp-/DsDataSourceTemplate9162352335796065232-ds.xml
> is created, but when the file is accessed by the vfs, it fails with:
> java.io.FileNotFoundException: /var/folders/jY/jY1BDqLkHKO a4nm GooZE   TI/-Tmp-/DsDataSourceTemplate9162352335796065232-ds.xml

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

        


From jira-events at lists.jboss.org  Tue Jul 14 09:31:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Tue, 14 Jul 2009 09:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7085) Replace ejb3 secured
 profile service facade with secured remoting proxy
In-Reply-To: <1810173299.1247085411421.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1272390950.1247578289491.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7085:
---------------------------------

    Priority: Critical  (was: Major)


> Replace ejb3 secured profile service facade with secured remoting proxy
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7085
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7085
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService, Security
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Its been decided to limit the number of dependencies an admin client needs to communicate with a secured profile service. We need to drop the ejb3 facade and provide a secured remoting based proxy bound in global jndi and an unsecured, but security manager controlled unsecured proxy under the java: local jndi namespace.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 09:33:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Tue, 14 Jul 2009 09:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7074) some jars required
 by remote Profile Service clients are not included in client/ or
 client/jbossall-client.jar's Manifest classpath
In-Reply-To: <631441563.1246562451433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1399819725.1247578409183.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7074:
---------------------------------

    Labels: profileservice  (was: )


> some jars required by remote Profile Service clients are not included in client/ or client/jbossall-client.jar's Manifest classpath
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7074
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7074
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The following jar is missing from client/jbossall-client.jar's Manifest classpath and from client/:
>    common/lib/jboss-security-aspects.jar
> Its corresponding Maven artifact is org.jboss.aspects:jboss-security-aspects.
> If I find any others, I will update this JIRA.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 09:37:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Tue, 14 Jul 2009 09:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7097) Stack overflow
 error when establishing secured connection to Profile Service
Message-ID: <740224745.1247578649409.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476207#action_12476207 ] 

Charles Crouch commented on JBAS-7097:
--------------------------------------

(8:23:33 AM) ips: stackoverflowerror in the new aop security code...
(8:32:50 AM) ccrouch: "new" as in from JBAS-7085 or new from JOPR-263 ?
(8:33:17 AM) ips: 7085 i think
(8:33:56 AM) ips: 263 was working great on my box - tested pretty thoroughly
(8:34:23 AM) ips: lukas saw this for the first time this morning after updating his EAP build to the latest 

> Stack overflow error when establishing secured connection to Profile Service
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7097
>             Project: JBoss Application Server
>          Issue Type: Bug
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Jopr rev902, AS5 EAP rev91190
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The stack overflow occurs in Jopr AS5 plugin AbstractProfileServiceConnection.init() after the connection has been established.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
>         at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
> Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
>         at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
>         at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
>         ... 12 more                                                                                                                                                                       
> Caused by: java.lang.StackOverflowError                                                                                                                                                   
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
> ....                                                                           
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
>         ... 18 more                                                                                                                                                                       

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

        


From jira-events at lists.jboss.org  Tue Jul 14 10:02:42 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 14 Jul 2009 10:02:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <64958667.1247580162076.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert updated JBAS-7032:
-------------------------------

    Attachment: WhatUpDawg.ear


Corrected version with jars in WEB-INF/lib instead of ear root

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 10:08:30 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 14 Jul 2009 10:08:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <1734300986.1247580510070.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476221#action_12476221 ] 

Stan Silvert commented on JBAS-7032:
------------------------------------

You can reproduce this by dropping the new ear into /deploy on jboss-5.1.0.GA.

The reason admin-console is using WBPhaseListener is because it is there.  When admin-console starts up, JSF sees the path /webbeans.deployer/lib-int/faces on its classpath.  JSF searches its classpath for META-INF/faces-config.xml files.  When it see the faces-config.xml for webbeans it installs the WBPhaseListener.

So I think the problem is that the WB deployer is putting itself on the classpath in such a way that the admin-console sees it.  admin-console shoudn't know anything about the /webbeans.deployer/lib-int/faces directory.

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 10:12:29 2009
From: jira-events at lists.jboss.org (Michal Rorat (JIRA))
Date: Tue, 14 Jul 2009 10:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7092) Server fails to
 deploy war files in ear.
In-Reply-To: <775540505.1247229042120.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2121990198.1247580749527.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476226#action_12476226 ] 

Michal Rorat commented on JBAS-7092:
------------------------------------

I was able to drill down this issue to one of JBoss classes. I was debugging even deeper but without success...

org.jboss.web.AbstractWebDeployer:500

<code>
         envCtx.bind("UserTransaction", new LinkRef("UserTransaction"));
</code>

JBoss is binding UserTransaction, but for some reason for any module which is deployed as 34th this name is already registered in NamingServer - like I said before - even when the module is an empty jar or war.

For now we are using workaround (really nasty one) where we are deleting everything from NamingServer each time we are deploying module. So the code loks like that:

org.jboss.web.AbstractWebDeployer:500

<code>
         ((NamingServer)((NamingContext)envCtx).getNaming()).deleteAllBindings();
         envCtx.bind("UserTransaction", new LinkRef("UserTransaction"));
</code>

and org.jnp.server.NamingServer change:

<code>
   public void deleteAllBindings()
   {
	   table = new Hashtable();
   }
</code>

Maybe this will help to resolve the issue.

Regards,
Michal Rorat

> Server fails to deploy war files in ear.
> ----------------------------------------
>
>                 Key: JBAS-7092
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7092
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-4.2.3.GA
>         Environment: Windows XP 32 bit
> Windows 2003 Server
>            Reporter: Michal Rorat
>            Assignee: Ales Justin
>
> I have an ear file which contains ejbs and wars. It started to fail when I added sars. The problem is, it doesn't matter what wars I'm deploying, its always the second one and nothing gets deployed after this exception.
> aplication.xml file:
> <?xml version="1.0" encoding="UTF-8"?>
> <application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:application="http://java.sun.com/xml/ns/javaee/application_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd" id="Application_ID" version="5">
>   <module>
>     <java>OracleQueue.sar</java>
>   </module>
>   <module>
>     <java>SONController.sar</java>
>   </module>
>   <module>
>     <ejb>Admin.jar</ejb>
>   </module>
>   <module>
>     <ejb>Settings.jar</ejb>
>   </module>
>   <module>
>     <ejb>Layer3Msg.jar</ejb>
>   </module>
>   <module>
>     <java>Layer3MsgLoader.sar</java>
>   </module>
>   <module>
>     <ejb>Layer3MsgMdb.jar</ejb>
>   </module>
>   <module>
>     <ejb>Common.jar</ejb>
>   </module>
>   <module>
>     <ejb>Attributes.jar</ejb>
>   </module>
>   <module>
>     <ejb>Data.jar</ejb>
>   </module>
>   <module>
>     <ejb>Model.jar</ejb>
>   </module>
>   <module>
>     <ejb>Users.jar</ejb>
>   </module>
>   <module>
>     <ejb>Tasks.jar</ejb>
>   </module>
>   <module>
>     <ejb>Survey.jar</ejb>
>   </module>
>   <module>
>     <ejb>BenchmarkQpis.jar</ejb>
>   </module>
>   <module>
>     <ejb>Cellrefutils.jar</ejb>
>   </module>
>   <module>
>     <ejb>ConfigChanges.jar</ejb>
>   </module>
>   <module>
>     <ejb>Engine.jar</ejb>
>   </module>
>   <module>
>     <ejb>Events.jar</ejb>
>   </module>
>   <module>
>     <ejb>QueryDefs.jar</ejb>
>   </module>
>   <module>
>     <ejb>QueryData.jar</ejb>
>   </module>
>   <module>
>     <ejb>GeoTagging.jar</ejb>
>   </module>
>   <module>
>     <ejb>Kpievents.jar</ejb>
>   </module>
>   <module>
>     <ejb>Modules.jar</ejb>
>   </module>
>   <module>
>     <ejb>Network.jar</ejb>
>   </module>
>   <module>
>     <ejb>Qpis.jar</ejb>
>   </module>
>   <module>
>     <ejb>RadioNetworkAnalysis.jar</ejb>
>   </module>
>   <module>
>     <ejb>VirtualEarth.jar</ejb>
>   </module>
>   <module>
>     <ejb>WMS.jar</ejb>
>   </module>
>   <module>
>     <ejb>ReportData.jar</ejb>
>   </module>
>   <module>
>     <ejb>ReportsMetadata.jar</ejb>
>   </module>
>   <module>
>     <ejb>ReportProducer.jar</ejb>
>   </module>
>   <module>
>     <web>
>       <web-uri>Quorre.war</web-uri>
>       <context-root>ActixOne/Quorre</context-root>
>     </web>
>   </module>
>   <module>
>     <web>
>       <web-uri>TestWar.war</web-uri>
>       <context-root>TestWar</context-root>
>     </web>
>   </module>
>   <module>
>     <web>
>       <web-uri>Download.war</web-uri>
>       <context-root>ActixOne/Download</context-root>
>     </web>
>   </module>
> </application>
> Exception:
> 2009-07-10 12:28:30,687 INFO  [org.jboss.ejb3.EJB3Deployer] Deployed: file:/C:/jboss-4.2/server/default/tmp/deploy/tmp4660403835223254272ActixOne.ear-contents/ReportProducer.jar
> 2009-07-10 12:28:30,687 INFO  [org.jboss.web.tomcat.service.TomcatDeployer] deploy, ctxPath=/ActixOne/Quorre, warUrl=.../tmp/deploy/tmp4660403835223254272ActixOne.ear-contents/Quorre-exp.war/
> 2009-07-10 12:28:30,875 INFO  [org.rhq.helpers.rtfilter.filter.RtFilter] Initialized response-time filter for webapp with context root 'ActixOne/Quorre'.
> 2009-07-10 12:28:31,687 INFO  [org.jboss.web.tomcat.service.TomcatDeployer] deploy, ctxPath=/TestWar, warUrl=.../tmp/deploy/tmp4660403835223254272ActixOne.ear-contents/TestWar-exp.war/
> 2009-07-10 12:28:31,687 WARN  [org.jboss.system.ServiceController] Problem starting service jboss.web.deployment:war=TestWar.war,id=2043149425
> org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)
> 	at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:384)
> 	at org.jboss.web.WebModule.startModule(WebModule.java:83)
> 	at org.jboss.web.WebModule.startService(WebModule.java:61)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> 	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> 	at $Proxy0.start(Unknown Source)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:417)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.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 $Proxy45.start(Unknown Source)
> 	at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:466)
> 	at sun.reflect.GeneratedMethodAccessor85.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
> 	at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
> 	at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:87)
> 	at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
> 	at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
> 	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 $Proxy46.start(Unknown Source)
> 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
> 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> 	at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.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(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> 	at $Proxy0.start(Unknown Source)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:417)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.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:304)
> 	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(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.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(Unknown Source)
> Caused by: javax.naming.NameAlreadyBoundException
> 	at org.jnp.server.NamingServer.bind(NamingServer.java:144)
> 	at org.jnp.interfaces.NamingContext.bind(NamingContext.java:591)
> 	at org.jnp.interfaces.NamingContext.bind(NamingContext.java:552)
> 	at org.jboss.web.AbstractWebDeployer.parseWebAppDescriptors(AbstractWebDeployer.java:495)
> 	at org.jboss.web.AbstractWebDeployer$DescriptorParser.parseWebAppDescriptors(AbstractWebDeployer.java:878)
> 	at org.jboss.web.tomcat.service.TomcatDeployer.performDeployInternal(TomcatDeployer.java:159)
> 	at org.jboss.web.tomcat.service.TomcatDeployer.performDeploy(TomcatDeployer.java:104)
> 	at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:375)
> 	... 112 more
> 2009-07-10 12:28:31,718 ERROR [org.jboss.deployment.MainDeployer] Could not start deployment: file:/C:/jboss-4.2/server/default/tmp/deploy/tmp4660403835223254272ActixOne.ear-contents/TestWar.war
> org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)
> 	at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:384)
> 	at org.jboss.web.WebModule.startModule(WebModule.java:83)
> 	at org.jboss.web.WebModule.startService(WebModule.java:61)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> 	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> 	at $Proxy0.start(Unknown Source)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:417)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.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 $Proxy45.start(Unknown Source)
> 	at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:466)
> 	at sun.reflect.GeneratedMethodAccessor85.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
> 	at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
> 	at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:87)
> 	at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
> 	at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
> 	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 $Proxy46.start(Unknown Source)
> 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
> 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> 	at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.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(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> 	at $Proxy0.start(Unknown Source)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:417)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.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:304)
> 	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(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.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(Unknown Source)
> Caused by: javax.naming.NameAlreadyBoundException
> 	at org.jnp.server.NamingServer.bind(NamingServer.java:144)
> 	at org.jnp.interfaces.NamingContext.bind(NamingContext.java:591)
> 	at org.jnp.interfaces.NamingContext.bind(NamingContext.java:552)
> 	at org.jboss.web.AbstractWebDeployer.parseWebAppDescriptors(AbstractWebDeployer.java:495)
> 	at org.jboss.web.AbstractWebDeployer$DescriptorParser.parseWebAppDescriptors(AbstractWebDeployer.java:878)
> 	at org.jboss.web.tomcat.service.TomcatDeployer.performDeployInternal(TomcatDeployer.java:159)
> 	at org.jboss.web.tomcat.service.TomcatDeployer.performDeploy(TomcatDeployer.java:104)
> 	at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:375)
> 	... 112 more
> 2009-07-10 12:28:31,718 ERROR [org.jboss.deployment.scanner.URLDeploymentScanner] Incomplete Deployment listing:
> --- Incompletely deployed packages ---
> org.jboss.deployment.DeploymentInfo at 11dba24c { url=file:/C:/jboss-4.2/server/default/deploy/ActixOne.ear }
>   deployer: org.jboss.deployment.EARDeployer at 7981d5
>   status: Deployment FAILED reason: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)
>   state: FAILED
>   watch: file:/C:/jboss-4.2/server/default/deploy/ActixOne.ear
>   altDD: null
>   lastDeployed: 1247225246750
>   lastModified: 1247225222906
>   mbeans:
>     jboss.j2ee:ear=ActixOne.ear,jar=Admin.jar,name=Admin,service=EJB3 state: Started
>     persistence.units:ear=ActixOne.ear,jar=Settings.jar,unitName=SettingsStorage state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Settings.jar,name=Settings,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Layer3Msg.jar,name=Layer3Msg,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Layer3MsgMdb.jar,name=ReportProducerMDB,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Common.jar,name=Common,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Attributes.jar,name=Attributes,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Data.jar,name=Data,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Model.jar,name=Model,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Users.jar,name=Users,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Tasks.jar,name=Tasks,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Survey.jar,name=Survey,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=BenchmarkQpis.jar,name=Benchmarkqpis,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Cellrefutils.jar,name=Cellrefutils,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=ConfigChanges.jar,name=Configchanges,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Engine.jar,name=Engine,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Events.jar,name=Events,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=QueryDefs.jar,name=QueryDefs,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=QueryData.jar,name=QueryData,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=GeoTagging.jar,name=Geotagging,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Kpievents.jar,name=Kpievents,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Modules.jar,name=Modules,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Network.jar,name=Network,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Qpis.jar,name=Qpis,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=RadioNetworkAnalysis.jar,name=RadioNetworkAnalysis,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=VirtualEarth.jar,name=VirtualEarth,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=WMS.jar,name=Wms,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=ReportData.jar,name=ReportData,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=ReportsMetadata.jar,name=ReportsMetadata,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=ReportProducer.jar,name=ReportProducerMDB,service=EJB3 state: Started
> --- MBeans waiting for other MBeans ---
> ObjectName: jboss:service=KeyGeneratorFactory,type=HiLo
>   State: CONFIGURED
>   I Depend On:
>     jboss:service=TransactionManager
>     jboss.jca:service=DataSourceBinding,name=DefaultDS
> ObjectName: jboss.cache:service=InvalidationBridge,type=JavaGroups
>   State: CONFIGURED
>   I Depend On:
>     jboss:service=DefaultPartition
>     jboss.cache:service=InvalidationManager
> ObjectName: jboss.mq:service=InvocationLayer,type=HTTP
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=Invoker
>     jboss.web:service=WebServer
> ObjectName: jboss.mq:service=StateManager
>   State: CONFIGURED
>   I Depend On:
>     jboss.jca:service=DataSourceBinding,name=DefaultDS
>   Depends On Me:
>     jboss.mq:service=DestinationManager
> ObjectName: jboss.mq:service=DestinationManager
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=MessageCache
>     jboss.mq:service=PersistenceManager
>     jboss.mq:service=StateManager
>     jboss.mq:service=ThreadPool
>     jboss:service=Naming
>   Depends On Me:
>     jboss.mq.destination:service=Topic,name=testTopic
>     jboss.mq.destination:service=Topic,name=securedTopic
>     jboss.mq.destination:service=Topic,name=testDurableTopic
>     jboss.mq.destination:service=Queue,name=testQueue
>     jboss.mq.destination:service=Queue,name=A
>     jboss.mq.destination:service=Queue,name=B
>     jboss.mq.destination:service=Queue,name=C
>     jboss.mq.destination:service=Queue,name=D
>     jboss.mq.destination:service=Queue,name=ex
>     jboss.mq:service=SecurityManager
>     jboss.mq.destination:service=Queue,name=DLQ
> ObjectName: jboss.mq:service=PersistenceManager
>   State: CONFIGURED
>   I Depend On:
>     jboss.jca:service=DataSourceBinding,name=DefaultDS
>   Depends On Me:
>     jboss.mq:service=DestinationManager
> ObjectName: jboss.mq.destination:service=Topic,name=testTopic
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
>     jboss.mq:service=SecurityManager
> ObjectName: jboss.mq.destination:service=Topic,name=securedTopic
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
>     jboss.mq:service=SecurityManager
> ObjectName: jboss.mq.destination:service=Topic,name=testDurableTopic
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
>     jboss.mq:service=SecurityManager
> ObjectName: jboss.mq.destination:service=Queue,name=testQueue
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
>     jboss.mq:service=SecurityManager
> ObjectName: jboss.mq.destination:service=Queue,name=A
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
> ObjectName: jboss.mq.destination:service=Queue,name=B
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
> ObjectName: jboss.mq.destination:service=Queue,name=C
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
> ObjectName: jboss.mq.destination:service=Queue,name=D
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
> ObjectName: jboss.mq.destination:service=Queue,name=ex
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
> ObjectName: jboss.mq:service=Invoker
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=TracingInterceptor
>     jboss:service=Naming
>   Depends On Me:
>     jboss.mq:service=InvocationLayer,type=HTTP
>     jboss.mq:service=InvocationLayer,type=JVM
>     jboss.mq:service=InvocationLayer,type=UIL2
> ObjectName: jboss.mq:service=TracingInterceptor
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=SecurityManager
>   Depends On Me:
>     jboss.mq:service=Invoker
> ObjectName: jboss.mq:service=SecurityManager
>   State: CONFIGURED
>   I Depend On:
>     jboss.security:service=JaasSecurityManager
>     jboss.mq:service=DestinationManager
>   Depends On Me:
>     jboss.mq.destination:service=Topic,name=testTopic
>     jboss.mq.destination:service=Topic,name=securedTopic
>     jboss.mq.destination:service=Topic,name=testDurableTopic
>     jboss.mq.destination:service=Queue,name=testQueue
>     jboss.mq:service=TracingInterceptor
>     jboss.mq.destination:service=Queue,name=DLQ
> ObjectName: jboss.mq.destination:service=Queue,name=DLQ
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
>     jboss.mq:service=SecurityManager
> ObjectName: jboss.mq:service=InvocationLayer,type=JVM
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=Invoker
> ObjectName: jboss.mq:service=InvocationLayer,type=UIL2
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=Invoker
> ObjectName: jboss.web.deployment:war=TestWar.war,id=2043149425
>   State: FAILED
>   Reason: org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)
> --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
> ObjectName: jboss.web.deployment:war=TestWar.war,id=2043149425
>   State: FAILED
>   Reason: org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)
> ObjectName: jboss.cache:service=InvalidationManager
>   State: NOTYETINSTALLED
>   Depends On Me:
>     jboss.cache:service=InvalidationBridge,type=JavaGroups
> ObjectName: jboss.jca:service=DataSourceBinding,name=DefaultDS
>   State: NOTYETINSTALLED
>   Depends On Me:
>     jboss:service=KeyGeneratorFactory,type=HiLo
>     jboss.mq:service=StateManager
>     jboss.mq:service=PersistenceManager
> *********************************************************************
> I found out that I'm not the only one with problem like that:
> http://www.techienuggets.com/Detail?tx=27457
> Regards,
> Michal Rorat

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

        


From jira-events at lists.jboss.org  Tue Jul 14 10:16:29 2009
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Tue, 14 Jul 2009 10:16:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2431) SQLException on
 user login if hibernate schema name is specified
Message-ID: <1066866667.1247580989444.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SQLException on user login if hibernate schema name is specified
----------------------------------------------------------------

                 Key: JBPORTAL-2431
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2431
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal CMS
    Affects Versions: 2.7.2 Final
         Environment: JBoss Portal set up with a dedicated schema name (eg. on Oracle), <property name="hibernate.default_schema">epp43</property> added to all hibernate config files:

deploy/jboss-portal.sar/portal-cms.sar/conf/hibernate/cms/hibernate.cfg.xml
deploy/jboss-portal.sar/conf/hibernate/portal/hibernate.cfg.xml
deploy/jboss-portal.sar/conf/hibernate/portlet/hibernate.cfg.xml
deploy/jboss-portal.sar/conf/hibernate/workflow/hibernate.cfg.xml
deploy/jboss-portal.sar/conf/hibernate/user/hibernate.cfg.xml
deploy/jboss-portal.sar/conf/hibernate/instance/hibernate.cfg.xml
deploy/jboss-portal.sar/portal-wsrp.sar/conf/hibernate/consumer/hibernate.cfg.xml

            Reporter: Martin Putz
            Assignee: Sohil Shah


2009-07-13 12:24:30,751 DEBUG [org.hibernate.SQL] SELECT p.* 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=?
2009-07-13 12:24:30,751 DEBUG [org.hibernate.type.StringType] binding 'ora2' to parameter: 1
2009-07-13 12:24:30,762 WARN  [org.hibernate.util.JDBCExceptionReporter] SQL Error: 942, SQLState: 42000
2009-07-13 12:24:30,763 ERROR [org.hibernate.util.JDBCExceptionReporter] ORA-00942: table or view does not exist

2009-07-13 12:24:30,763 ERROR [org.jboss.portal.cms.security.AuthorizationProviderImpl] org.jboss.portal.cms.security.AuthorizationProviderImpl at 12f1015
org.hibernate.exception.SQLGrammarException: could not execute query
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:67)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.loader.Loader.doList(Loader.java:2223)
at org.hibernate.loader.Loader.listUsingQueryCache(Loader.java:2136)
at org.hibernate.loader.Loader.list(Loader.java:2096)
at org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:289)
at org.hibernate.impl.SessionImpl.listCustomQuery(SessionImpl.java:1695)
at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:142)
at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:152)
at org.jboss.portal.cms.security.AuthorizationProviderImpl.findPermissionsByUser(AuthorizationProviderImpl.java:454)
...
Caused by: java.sql.SQLException: ORA-00942: table or view does not exist



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

        


From jira-events at lists.jboss.org  Tue Jul 14 10:41:29 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Tue, 14 Jul 2009 10:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2048793468.1247582489270.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------

    Description: 
we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.

the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
- close session/connection after this many rollback() operations, e.g. 100
- close session/connection after all messages have been received (and removed)
- clustered vs. not clustered makes no difference
- hypersonic vs. db2 makes no difference
- adding a DLQ makes no difference
- DeliveryMode.NON_PERSISTENT makes no difference

the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
session.commit() operations (x thousands and more) do not lead to a leak
we do not use XA.

thanks for your help.

  was:
we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.

the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
- close session/connection after so many rollback() operation, e.g. 100
- close session/connection after all messages have been received (and removed)
- clustered vs. not clustered makes no difference
- hypersonic vs. db2 makes no difference
- adding a DLQ makes no difference
- DeliveryMode.NON_PERSISTENT makes no difference

the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
we do not use XA.

thanks for your help.



> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Tim Fox
>             Fix For: 1.4.3.GA
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 11:12:30 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Tue, 14 Jul 2009 11:12:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <1673450328.1247584350013.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476247#action_12476247 ] 

Ales Justin commented on JBAS-7032:
-----------------------------------

>> So I think the problem is that the WB deployer is putting itself on the classpath in such a way that the admin-console sees it.

Can you check/debug why this is so?

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 11:42:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 14 Jul 2009 11:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2207) Session entry
 points cache is not being update on dynamic additions
Message-ID: <520287620.1247586149328.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Session entry points cache is not being update on dynamic additions
-------------------------------------------------------------------

                 Key: JBRULES-2207
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2207
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler, drools-core
    Affects Versions: 5.0.1.FINAL, 5.0.0.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


package org.jboss.test.sam.drools;

import org.jboss.test.sam.drools.StockTick;

# default dialect
dialect "mvel"

# flag as event
declare StockTick
    @role( event )
end

# simple rule
rule "stream input test"
when
   $st: StockTick() from entry-point "in-channel"
then
   System.out.println("->"+$st);
end



java.lang.NullPointerException
        at org.drools.reteoo.EntryPointNode.updateSink(EntryPointNode.java:285)
        at org.drools.reteoo.ObjectTypeNode.attach(ObjectTypeNode.java:279)
        at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:160)
        at org.drools.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:289)
        at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:117)
        at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:70)
        at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:126)
        at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:73)
        at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:153)
        at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:126)
        at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
        at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:362)
        at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:618)
        at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:500)
        at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:379)
        at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:121)

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

        


From jira-events at lists.jboss.org  Tue Jul 14 11:44:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 14 Jul 2009 11:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2207) Session entry
 points cache is not being update on dynamic additions
In-Reply-To: <520287620.1247586149328.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1295053659.1247586269160.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2207.
----------------------------------

    Resolution: Done


Fixed.

> Session entry points cache is not being update on dynamic additions
> -------------------------------------------------------------------
>
>                 Key: JBRULES-2207
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2207
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler, drools-core
>    Affects Versions: 5.0.0.FINAL, 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> package org.jboss.test.sam.drools;
> import org.jboss.test.sam.drools.StockTick;
> # default dialect
> dialect "mvel"
> # flag as event
> declare StockTick
>     @role( event )
> end
> # simple rule
> rule "stream input test"
> when
>    $st: StockTick() from entry-point "in-channel"
> then
>    System.out.println("->"+$st);
> end
> java.lang.NullPointerException
>         at org.drools.reteoo.EntryPointNode.updateSink(EntryPointNode.java:285)
>         at org.drools.reteoo.ObjectTypeNode.attach(ObjectTypeNode.java:279)
>         at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:160)
>         at org.drools.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:289)
>         at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:117)
>         at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:70)
>         at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:126)
>         at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:73)
>         at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:153)
>         at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:126)
>         at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
>         at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:362)
>         at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:618)
>         at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:500)
>         at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:379)
>         at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:121)

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

        


From jira-events at lists.jboss.org  Tue Jul 14 12:11:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Jul 2009 12:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7048) Switch HAPartition to
 LongRunningTasksThreadPool
In-Reply-To: <20000345.1245771776621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <320366201.1247587889212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7048.
----------------------------------

    Resolution: Done


> Switch HAPartition to LongRunningTasksThreadPool
> ------------------------------------------------
>
>                 Key: JBAS-7048
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7048
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Now uses "ThreadPool" but for a long running task.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 12:13:29 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 14 Jul 2009 12:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-217)
 SchemaBindingValidator: extended XSD choice is not recognized
Message-ID: <694723892.1247588009184.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SchemaBindingValidator: extended XSD choice is not recognized
-------------------------------------------------------------

                 Key: JBXB-217
                 URL: https://jira.jboss.org/jira/browse/JBXB-217
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.2.Beta1
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: JBossXB-2.0.2.GA


Xerces XSD model for something like

   <xsd:complexType name="classloaderType" mixed="true">
      <xsd:complexContent>
         <xsd:extension base="classLoaderValueType"/>
      </xsd:complexContent>
   </xsd:complexType>

where classLoaderValueType is a choice will be represented by xerces as

sequence[choice[classLoaderValueType's choice content], sequence[]]

One of the confusing parts is the empty sequence at the end. Validator should be able to recognize a structure like this and treat it as a choice.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 12:17:29 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 14 Jul 2009 12:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-217)
 SchemaBindingValidator: extended XSD choice is not recognized
In-Reply-To: <694723892.1247588009184.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <621685161.1247588249501.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBXB-217.
----------------------------------

    Resolution: Done


Fixed.

> SchemaBindingValidator: extended XSD choice is not recognized
> -------------------------------------------------------------
>
>                 Key: JBXB-217
>                 URL: https://jira.jboss.org/jira/browse/JBXB-217
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.2.Beta1
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossXB-2.0.2.GA
>
>
> Xerces XSD model for something like
>    <xsd:complexType name="classloaderType" mixed="true">
>       <xsd:complexContent>
>          <xsd:extension base="classLoaderValueType"/>
>       </xsd:complexContent>
>    </xsd:complexType>
> where classLoaderValueType is a choice will be represented by xerces as
> sequence[choice[classLoaderValueType's choice content], sequence[]]
> One of the confusing parts is the empty sequence at the end. Validator should be able to recognize a structure like this and treat it as a choice.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 12:38:29 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 14 Jul 2009 12:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7085) Replace ejb3
 secured profile service facade with secured remoting proxy
In-Reply-To: <1810173299.1247085411421.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <909912127.1247589509681.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476261#action_12476261 ] 

Scott M Stark commented on JBAS-7085:
-------------------------------------

1) The jndi binding names are set by the following 3 jndiName properties of the ProfileServiceProxyFactory:

    <bean name="ProfileServiceProxyFactory" class="org.jboss.profileservice.remoting.ProxyFactory">
...
        <property name="jndiName">ProfileService</property>
        <property name="mgtViewJndiName">ManagementView</property>
        <property name="deployMgrJndiName">DeploymentManager</property>

2) the local unsecured ProfileService is only available via injection from the "ProfileService" MC bean. The unsecured ManagementView and DeploymentManager are available from that bean.

Authentication is enabled by default. To disable it the serverProxyInterceptors property of the ProfileServiceProxyFactory bean would have to be removed/set to an empty list vs the following default:

        <!-- Server side security interceptor stack -->
        <property name="serverProxyInterceptors">
            <list>
                <bean class="org.jboss.aspects.security.AuthenticationInterceptor">
                    <constructor>
                        <parameter>
                            <!-- AuthenticationManager -->
                            <value-factory bean="JNDIBasedSecurityManagement" method="getAuthenticationManager"
                            parameter="jmx-console"/>
                        </parameter>
                    </constructor>
                </bean>
                <bean class="org.jboss.aspects.security.RoleBasedAuthorizationInterceptor">
                    <constructor>
                        <!-- AuthenticationManager -->
                        <parameter>
                            <value-factory bean="JNDIBasedSecurityManagement" method="getAuthenticationManager"
                                parameter="jmx-console"/>
                        </parameter>
                        <!-- RealmMapping, the AuthenticationManager impl currently supports this -->
                        <parameter>
                            <value-factory bean="JNDIBasedSecurityManagement" method="getAuthenticationManager"
                                parameter="jmx-console"/>
                        </parameter>
                    </constructor>
                </bean>
            </list>
        </property>

> Replace ejb3 secured profile service facade with secured remoting proxy
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7085
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7085
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService, Security
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Its been decided to limit the number of dependencies an admin client needs to communicate with a secured profile service. We need to drop the ejb3 facade and provide a secured remoting based proxy bound in global jndi and an unsecured, but security manager controlled unsecured proxy under the java: local jndi namespace.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 13:26:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Jul 2009 13:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7054) Allow configuring of
 Manager for distributable webapps via context.xml
In-Reply-To: <9414961.1245871139577.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2011859054.1247592389172.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7054.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


Note that the commits for this on trunk can be found under JBAS-7095; I inadvertently didn't use a separate commit.

> Allow configuring of Manager for distributable webapps via context.xml
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7054
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7054
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Tomcat) service
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> TomcatDeployment will currently always replace the session Manager impl for contexts it creates if the distributable flag is set in web.xml.  Add a flag to TomcatDeployer disable this behavior. This will allow use of a Manager configured via context.xml.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 13:28:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Jul 2009 13:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7091) Incorrect handling of
 timestamps in clustered session
In-Reply-To: <2099065379.1247195609545.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1854941497.1247592509156.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7091.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> Incorrect handling of timestamps in clustered session
> -----------------------------------------------------
>
>                 Key: JBAS-7091
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7091
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Tomcat) service
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> ClusteredSession has an "outdatedTime" field that records the timestamp when a session gets a callback notifying of a modification on another node.  If the session state later gets updated from the distributed cache, the clearOutdated() method ends up setting the session timestamp to that "outdatedTime" rather than the correct timestamp that's stored in the distributed cache. That's wrong.
> Not a big deal, as the difference between the outdatedTime and the correct timestamp is probably just a few ms (time it takes to replicate the session). But still, it's wrong.
> In any case the handling of "outdatedTime" is more complex than need and related "outdatedVersion" field can be removed altogether.  There's a bit of cruft here from the old days when correct timestamps weren't readily available from the cache.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 13:36:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Jul 2009 13:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7095) HA Web Sessions
 via Database Persistence
In-Reply-To: <1302881808.1247516429179.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1808038017.1247592989155.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476269#action_12476269 ] 

Brian Stansberry commented on JBAS-7095:
----------------------------------------

Code for this is currently in Branch_5_x, JBPAPP_5_0 and trunk. JIRA remains open pending some ongoing evaluation in the community.

> HA Web Sessions via Database Persistence
> ----------------------------------------
>
>                 Key: JBAS-7095
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7095
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Tomcat) service
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Occasionally we receive input from the JBoss AS user community that they'd like to see an option to use database persistence as a mechanism to make web sessions highly available. The basic use case we here for this is environments where sessions need to be available to AS instances located across a WAN. JBoss Cache/JGroups clusters can span a WAN but often users find it impractical to configure their cluster(s) in that way. However, their IT infrastructure already supports making RDBMS data accessible across the WAN. So, persisting sessions to the DB makes them available across the WAN.
> This JIRA is to create a session Manager impl that satisfies this request. It will be based on the distributed session manager code that we use with JBoss Cache replication, but the implementation of the DistributedCacheManager SPI that manager uses will be replaced with a version the interacts with a RDMBS.
> See http://www.jboss.org/community/wiki/HAWebSessionsviaDatabasePersistence for details.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 13:41:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 14 Jul 2009 13:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <56079735.1247593289362.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert updated JBAS-7032:
-------------------------------

    Attachment: PrintResourcePathContextListener.class


> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: PrintResourcePathContextListener.class, PrintResourcePathContextListener.java, WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 13:39:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 14 Jul 2009 13:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <907668522.1247593169416.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476270#action_12476270 ] 

Stan Silvert commented on JBAS-7032:
------------------------------------

I have verified that the analysis was correct.  I created a ServletContextListener (attached) that finds faces-config.xml files in the same manner as JSF.  When WhatsUpDawg.ear is deployed, admin-console finds the faces-config.xml file in /webbeans.deployer/lib-int/faces/META-INF/faces-config.xml.  Here is the output:

13:29:12,581 INFO  [STDOUT] ******************************************
13:29:12,583 INFO  [STDOUT] ** Resource Paths for META-INF/faces-config.xml:
13:29:12,602 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/org.jboss.seam-jboss-seam-2.1.0.SP1.jar/META-INF/faces-config.xml
13:29:12,607 INFO  [STDOUT] vfsfile:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deployers/webbeans.deployer/lib-int/faces/META-INF/faces-config.xml
13:29:12,610 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/jsf-facelets-1.1.15.B1.jar/META-INF/faces-config.xml
13:29:12,614 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/jboss-seam-debug-2.1.0.SP1.jar/META-INF/faces-config.xml
13:29:12,619 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/richfaces-impl-3.3.0.GA.jar/META-INF/faces-config.xml
13:29:12,624 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/jboss-seam-ui-2.1.0.SP1.jar/META-INF/faces-config.xml
13:29:12,628 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/richfaces-ui-3.3.0.GA.jar/META-INF/faces-config.xml
13:29:12,632 INFO  [STDOUT] ******************************************

Without WhatsUpDawg.ear you get:

13:32:41,564 INFO  [STDOUT] ******************************************
13:32:41,568 INFO  [STDOUT] ** Resource Paths for META-INF/faces-config.xml:
13:32:41,602 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/org.jboss.seam-jboss-seam-2.1.0.SP1.jar/META-INF/faces-config.xml
13:32:41,606 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/jsf-facelets-1.1.15.B1.jar/META-INF/faces-config.xml
13:32:41,611 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/jboss-seam-debug-2.1.0.SP1.jar/META-INF/faces-config.xml
13:32:41,617 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/richfaces-impl-3.3.0.GA.jar/META-INF/faces-config.xml
13:32:41,622 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/jboss-seam-ui-2.1.0.SP1.jar/META-INF/faces-config.xml
13:32:41,627 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/richfaces-ui-3.3.0.GA.jar/META-INF/faces-config.xml
13:32:41,631 INFO  [STDOUT] ******************************************

To see this result, just add the attached class to /admin-console/WEB-INF/lib/classes.  Then put this in /admin-console/WEB-INF/web.xml:

    <listener>
       <listener-class>org.jboss.jbas7032.PrintResourcePathContextListener</listener-class>
    </listener>

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 13:41:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 14 Jul 2009 13:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <1305499751.1247593289526.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert updated JBAS-7032:
-------------------------------

    Attachment: PrintResourcePathContextListener.java


> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: PrintResourcePathContextListener.class, PrintResourcePathContextListener.java, WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 15:55:29 2009
From: jira-events at lists.jboss.org (Alexander Smirnov (JIRA))
Date: Tue, 14 Jul 2009 15:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2432)
 PortletRequestDispatcher does
 not execute 'forward' method during resource request.
Message-ID: <2086542322.1247601329145.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

PortletRequestDispatcher does not execute 'forward' method during resource request.
-----------------------------------------------------------------------------------

                 Key: JBPORTAL-2432
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2432
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core
         Environment: Jboss Portal 2.7 built from http://anonsvn.jboss.org/repos/portal/branches/JBoss_Portal_Branch_2_7 revision 13553 / Jboss AS 4.2.3.GA
            Reporter: Alexander Smirnov


By default, GenericFacesPortlet uses PortletRequestDispatcher.forward method to serve resources during resource requests. The code is:
	/**
	 * Default resource serving.
	 * <p>
	 * The default implemention of this method is to call a
	 * RequestDispatcher.foward with the ResourceID of the ResourceRequest.
	 * <p>
	 * If no ResourceID is set on the resource URL the default implementation
	 * does nothing.
	 * 
	 * @since 2.0
	 */
	public void serveResource(ResourceRequest request, ResourceResponse response) throws PortletException, IOException {
		if (request.getResourceID() != null) {
			PortletRequestDispatcher rd = getPortletConfig().getPortletContext().getRequestDispatcher(
					request.getResourceID());
			if (rd != null)
				rd.forward(request, response);
		}
	}
Never that code nor custom portletBridge code that uses 'forward' method doesn't work in Jboss Portal but works properly in other Portlet 2.0 implementations.
The same PortletRequestDispatcher.forward method works properly during render request.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 15:59:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Tue, 14 Jul 2009 15:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <1027816382.1247601569385.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476285#action_12476285 ] 

Ales Justin commented on JBAS-7032:
-----------------------------------

Did you try this against my latest WB fix (WBINT-16)?

Or why exactly does admin-console get that faces/ added from WBUrlIntegrationDeployer?
Or how does that resource creep in?

btw: did we fix that admin-console CL isolation issue?
(by having proper jboss-web.xml)

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: PrintResourcePathContextListener.class, PrintResourcePathContextListener.java, WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 16:14:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 14 Jul 2009 16:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-99) Create extensible
 AS Server implementation base
In-Reply-To: <1375381167.1247203301607.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <162918837.1247602469130.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-99.
---------------------------------------

    Resolution: Done


> Create extensible AS Server implementation base
> -----------------------------------------------
>
>                 Key: JBBOOT-99
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-99
>             Project: JBoss Bootstrap
>          Issue Type: Task
>          Components: impl-as
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 2.0.0-beta-1 
>
>
> JBossASEmbeddedServerImpl in the EMB project currently extends from JBossASServerImpl, which provides no generics to allow for covarient return.  As a result, the method chaining functions come back as JBossASServer instead of JBossASEmbeddedServer.  
> Make an extensible AS server implementation which keeps the generics chain alive.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 16:16:42 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 14 Jul 2009 16:16:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <976238844.1247602602303.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476287#action_12476287 ] 

Stan Silvert commented on JBAS-7032:
------------------------------------

No, I haven't tried it with the WBINT-16 fix.

I don't know exactly how the resource creeps in.  I can only conclude that it leaks from the deployment of WhatsUpDawg.ear.  So I'm guessing that when the WBDeployer puts /webbeans.deployer/lib-int/faces on the classpath then that makes it visible to all deployments.

Isolation of admin-console doesn't solve the problem since we can't ask everyone to isolate their apps just because a WebBeans app is running in the same AS instance.



> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: PrintResourcePathContextListener.class, PrintResourcePathContextListener.java, WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 16:43:29 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 14 Jul 2009 16:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <785223743.1247604209424.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-7032:
---------------------------------


RE: btw: did we fix that admin-console CL isolation issue? (by having proper jboss-web.xml)
The admin-console.war includes a jboss-web.xml with the following: 
<class-loading>
        <loader-repository>
            org.jboss.on:loader=embedded
            <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
        </loader-repository>
    </class-loading>

I have been looking at different app packaging to determine if there are other issues besides applications with web beans.  In addition to the web beans application, I have found that an EAR which includes SEAM/RF library jars in the EAR/lib directory *without* a jboss-app.xml (and EAR isolation is set to false by default in ear-deployer-jboss-beans.xml) also has the same problem; specifically, picking up another deployment's faces-config.xml .  Using Stan's ServletContextListener, the output with jboss-seam-booking (with jboss-app.xml removed):

2009-07-14 15:38:54,608 INFO  [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (main) deploy, ctxPath=/admin-console
2009-07-14 15:38:54,705 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (main) Initializing Mojarra (1.2_12-b01-FCS) for context '/admin-console'

2009-07-14 15:38:58,168 INFO  [STDOUT] (main) ******************************************
2009-07-14 15:38:58,168 INFO  [STDOUT] (main) ** Resource Paths for META-INF/faces-config.xml:
2009-07-14 15:38:58,201 INFO  [STDOUT] (main) vfszip:/work/EAP5/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/admin-console.war/WEB-INF/lib/richfaces-impl-3.3.0.GA.jar/META-INF/faces-config.xml
2009-07-14 15:38:58,202 INFO  [STDOUT] (main) vfszip:/work/EAP5/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/jboss-seam-booking.ear/jboss-seam.jar/META-INF/faces-config.xml
2009-07-14 15:38:58,202 INFO  [STDOUT] (main) vfszip:/work/EAP5/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/admin-console.war/WEB-INF/lib/jboss-seam-ui-2.1.0.SP1.jar/META-INF/faces-config.xml
2009-07-14 15:38:58,202 INFO  [STDOUT] (main) vfszip:/work/EAP5/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/admin-console.war/WEB-INF/lib/richfaces-ui-3.3.0.GA.jar/META-INF/faces-config.xml
2009-07-14 15:38:58,202 INFO  [STDOUT] (main) vfszip:/work/EAP5/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/admin-console.war/WEB-INF/lib/org.jboss.seam-jboss-seam-2.1.0.SP1.jar/META-INF/faces-config.xml
2009-07-14 15:38:58,202 INFO  [STDOUT] (main) vfszip:/work/EAP5/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/admin-console.war/WEB-INF/lib/jsf-facelets-1.1.15.B1.jar/META-INF/faces-config.xml
2009-07-14 15:38:58,202 INFO  [STDOUT] (main) vfszip:/work/EAP5/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/admin-console.war/WEB-INF/lib/jboss-seam-debug-2.1.0.SP1.jar/META-INF/faces-config.xml


Setting EAR isolation to true in ear-deployer-jboss-beans.xml or providing a jboss-app.xml, the faces-config.xml from the jboss-seam-booking app is not found and both apps work together.    

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: PrintResourcePathContextListener.class, PrintResourcePathContextListener.java, WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 16:53:29 2009
From: jira-events at lists.jboss.org (Wesley Hales (JIRA))
Date: Tue, 14 Jul 2009 16:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2432)
 PortletRequestDispatcher
 does not execute 'forward' method during resource request.
In-Reply-To: <2086542322.1247601329145.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1288278713.1247604809197.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476292#action_12476292 ] 

Wesley Hales commented on JBPORTAL-2432:
----------------------------------------

There are no tests for PortletRequestDispatcher.forward and there needs to be a test assessing that forward should work.
For now we will use the include method as a workaround.

Thomas, can you help out with this or re-assign?

> PortletRequestDispatcher does not execute 'forward' method during resource request.
> -----------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-2432
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2432
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>         Environment: Jboss Portal 2.7 built from http://anonsvn.jboss.org/repos/portal/branches/JBoss_Portal_Branch_2_7 revision 13553 / Jboss AS 4.2.3.GA
>            Reporter: Alexander Smirnov
>
> By default, GenericFacesPortlet uses PortletRequestDispatcher.forward method to serve resources during resource requests. The code is:
> 	/**
> 	 * Default resource serving.
> 	 * <p>
> 	 * The default implemention of this method is to call a
> 	 * RequestDispatcher.foward with the ResourceID of the ResourceRequest.
> 	 * <p>
> 	 * If no ResourceID is set on the resource URL the default implementation
> 	 * does nothing.
> 	 * 
> 	 * @since 2.0
> 	 */
> 	public void serveResource(ResourceRequest request, ResourceResponse response) throws PortletException, IOException {
> 		if (request.getResourceID() != null) {
> 			PortletRequestDispatcher rd = getPortletConfig().getPortletContext().getRequestDispatcher(
> 					request.getResourceID());
> 			if (rd != null)
> 				rd.forward(request, response);
> 		}
> 	}
> Never that code nor custom portletBridge code that uses 'forward' method doesn't work in Jboss Portal but works properly in other Portlet 2.0 implementations.
> The same PortletRequestDispatcher.forward method works properly during render request.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 16:53:29 2009
From: jira-events at lists.jboss.org (Wesley Hales (JIRA))
Date: Tue, 14 Jul 2009 16:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-2432)
 PortletRequestDispatcher
 does not execute 'forward' method during resource request.
In-Reply-To: <2086542322.1247601329145.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2010562096.1247604809304.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wesley Hales reassigned JBPORTAL-2432:
--------------------------------------

    Assignee: Thomas Heute


> PortletRequestDispatcher does not execute 'forward' method during resource request.
> -----------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-2432
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2432
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>         Environment: Jboss Portal 2.7 built from http://anonsvn.jboss.org/repos/portal/branches/JBoss_Portal_Branch_2_7 revision 13553 / Jboss AS 4.2.3.GA
>            Reporter: Alexander Smirnov
>            Assignee: Thomas Heute
>
> By default, GenericFacesPortlet uses PortletRequestDispatcher.forward method to serve resources during resource requests. The code is:
> 	/**
> 	 * Default resource serving.
> 	 * <p>
> 	 * The default implemention of this method is to call a
> 	 * RequestDispatcher.foward with the ResourceID of the ResourceRequest.
> 	 * <p>
> 	 * If no ResourceID is set on the resource URL the default implementation
> 	 * does nothing.
> 	 * 
> 	 * @since 2.0
> 	 */
> 	public void serveResource(ResourceRequest request, ResourceResponse response) throws PortletException, IOException {
> 		if (request.getResourceID() != null) {
> 			PortletRequestDispatcher rd = getPortletConfig().getPortletContext().getRequestDispatcher(
> 					request.getResourceID());
> 			if (rd != null)
> 				rd.forward(request, response);
> 		}
> 	}
> Never that code nor custom portletBridge code that uses 'forward' method doesn't work in Jboss Portal but works properly in other Portlet 2.0 implementations.
> The same PortletRequestDispatcher.forward method works properly during render request.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 16:57:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 14 Jul 2009 16:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1011) Release JGroups
	2.6.11
Message-ID: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Release JGroups 2.6.11
----------------------

                 Key: JGRP-1011
                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.6.11
            Reporter: Richard Achmatowicz
            Assignee: Richard Achmatowicz


This release is required for EAP.

Here are the fixes which are so far logged against this release:
Release Notes - JGroups - Version 2.6.11
** Bug
   * [JGRP-912] - Failed to parse the jgroups.xml file
   * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
   * [JGRP-985] - Flush and join problems during constant node failures and constant joins
   * [JGRP-986] - FLUSH: relax event sequencing for a joining member
   * [JGRP-997] - AUTH: incorrect matching of src against memberList
   * [JGRP-1000] - COMPRESS corrupts some messages
   * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
** Task
   * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
   * [JGRP-1004] - GroupRequest: don't ignore InterruptedException

Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
 
There are other IPv6 relared issues which also should be addressed, in particular JGRP-956.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 17:18:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 14 Jul 2009 17:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-100) Upgrade
 dependencies as part of 2.0.0-alpha-X release chain
Message-ID: <472570314.1247606309632.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade dependencies as part of 2.0.0-alpha-X release chain
-----------------------------------------------------------

                 Key: JBBOOT-100
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-100
             Project: JBoss Bootstrap
          Issue Type: Task
          Components: impl-as, impl-mc, spi
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger




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

        


From jira-events at lists.jboss.org  Tue Jul 14 17:52:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 14 Jul 2009 17:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <593991298.1247608349240.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1011:
--------------------------------------

    Description: 
This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.

Here are the fixes which are so far logged against this release:
Release Notes - JGroups - Version 2.6.11
** Bug
   * [JGRP-912] - Failed to parse the jgroups.xml file
   * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
   * [JGRP-985] - Flush and join problems during constant node failures and constant joins
   * [JGRP-986] - FLUSH: relax event sequencing for a joining member
   * [JGRP-997] - AUTH: incorrect matching of src against memberList
   * [JGRP-1000] - COMPRESS corrupts some messages
   * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
** Task
   * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
   * [JGRP-1004] - GroupRequest: don't ignore InterruptedException

Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
 
There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

  was:
This release is required for EAP.

Here are the fixes which are so far logged against this release:
Release Notes - JGroups - Version 2.6.11
** Bug
   * [JGRP-912] - Failed to parse the jgroups.xml file
   * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
   * [JGRP-985] - Flush and join problems during constant node failures and constant joins
   * [JGRP-986] - FLUSH: relax event sequencing for a joining member
   * [JGRP-997] - AUTH: incorrect matching of src against memberList
   * [JGRP-1000] - COMPRESS corrupts some messages
   * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
** Task
   * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
   * [JGRP-1004] - GroupRequest: don't ignore InterruptedException

Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
 
There are other IPv6 relared issues which also should be addressed, in particular JGRP-956.



> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 17:58:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 14 Jul 2009 17:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1704699721.1247608709092.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476296#action_12476296 ] 

Richard Achmatowicz commented on JGRP-1011:
-------------------------------------------

Applied changes to testsuite for IPv6 testing.
Fixed ConnectionTableTest and GossipRouterTest to eliminate dependence on localhost.


> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 18:32:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 14 Jul 2009 18:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7098) Upgrade
 jboss-bootstrap dependencies and refactor to match
Message-ID: <1310709585.1247610749408.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade jboss-bootstrap dependencies and refactor to match
----------------------------------------------------------

                 Key: JBAS-7098
                 URL: https://jira.jboss.org/jira/browse/JBAS-7098
             Project: JBoss Application Server
          Issue Type: Thirdparty Change
      Security Level: Public (Everyone can see)
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


With JBBOOT-99 we introduce an extensible JBossASBasedServer which must be used such that Embedded can take advantage of AS as well.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 18:38:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 14 Jul 2009 18:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7098) Upgrade
 jboss-bootstrap dependencies and refactor to match
In-Reply-To: <1310709585.1247610749408.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <840801243.1247611109147.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476298#action_12476298 ] 

Andrew Lee Rubinger commented on JBAS-7098:
-------------------------------------------

Need to merge r91266 into trunk

> Upgrade jboss-bootstrap dependencies and refactor to match
> ----------------------------------------------------------
>
>                 Key: JBAS-7098
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7098
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> With JBBOOT-99 we introduce an extensible JBossASBasedServer which must be used such that Embedded can take advantage of AS as well.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 18:44:29 2009
From: jira-events at lists.jboss.org (John Ament (JIRA))
Date: Tue, 14 Jul 2009 18:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <748704164.1247611469349.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476299#action_12476299 ] 

John Ament commented on JBAS-7032:
----------------------------------

just wondering, can you provide a demo jboss-app.xml that works around this?

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: PrintResourcePathContextListener.class, PrintResourcePathContextListener.java, WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 21:50:29 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 14 Jul 2009 21:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <1620374378.1247622629915.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-7032:
---------------------------------

    Attachment: jboss-app.xml


John, see attached is a jboss-app.xml 

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-app.xml, PrintResourcePathContextListener.class, PrintResourcePathContextListener.java, WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 21:58:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 14 Jul 2009 21:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2412) Update the logging
	framework
Message-ID: <1216275567.1247623109501.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBAS-2412.
-----------------------------

    Fix Version/s:     (was: JBossAS-5.2.0.Beta1)
       Resolution: Done


Merged into 6.x.  Open a new JIRA if a backport to 5.2 is required

> Update the logging framework
> ----------------------------
>
>                 Key: JBAS-2412
>                 URL: https://jira.jboss.org/jira/browse/JBAS-2412
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: Scott M Stark
>            Assignee: David Lloyd
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Its been a long time since we revisted the logging framework and the use of log4j as the default. I looked at having better seamless integration with the jdk java.util.logging framework using a port of the log4j appenders/layout to jdk handlers/formatters and the initial prototype is in head as mentioned in the linked forum thread.
> We need to reevaluate what the default logging implementation should be along with what updates the Log4jService needs. Some things to think about:
> 1. Using a log4j implementation that does not suffer from the current deadlock problem
> 2. How to nlog4j, slf4j, commons logging fit into the picture
> 3. Generalization of the Log4jService into one that works for whatever the default implementation is
> 3a. Add support for redirecting stderr, stdout to seperate log files instead of all loggers.

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

        


From jira-events at lists.jboss.org  Tue Jul 14 22:00:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 14 Jul 2009 22:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-6097) Move Log4jService
 into separate project
In-Reply-To: <18917230.1224054440898.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1949700421.1247623229585.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBAS-6097.
-----------------------------

    Fix Version/s:     (was: JBossAS-5.2.0.Beta1)
       Resolution: Done


> Move Log4jService into separate project
> ---------------------------------------
>
>                 Key: JBAS-6097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6097
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.0.0.CR2
>            Reporter: Scott M Stark
>            Assignee: David Lloyd
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> To pull the Log4jService into a bootstrap beans file it needs to be moved out of the jboss.jar and properly pojoized.
> The org.jboss.logging package from the server module is being moved to:
> https://svn.jboss.org/repos/jbossas/projects/log-services/

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

        


From jira-events at lists.jboss.org  Tue Jul 14 22:15:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 14 Jul 2009 22:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6789) Allow applications
 to override logging by placing a log4j.xml inside it
In-Reply-To: <4502880.1239799773655.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1648839381.1247624129292.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476305#action_12476305 ] 

David Lloyd commented on JBAS-6789:
-----------------------------------

Do you require support specifically for log4j deployments?  Or simply the ability for each deployment to provide its own logging configuration?

> Allow applications to override logging by placing a log4j.xml inside it
> -----------------------------------------------------------------------
>
>                 Key: JBAS-6789
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6789
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: Pete Muir
>            Assignee: David Lloyd
>


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

        


From jira-events at lists.jboss.org  Wed Jul 15 01:10:49 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 01:10:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1401) Unverified:
 Restarting a Queue will delete persistent messages in the queue.
In-Reply-To: <1348241.1216341592381.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <411598124.1247634649009.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1401:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> Unverified: Restarting a Queue will delete persistent messages in the queue.
> ----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1401
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1401
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3
>            Reporter: Jay Howell
>            Assignee: Howard Gao
>
> Restarting a queue in a running server will delete persistent messages out of the database.  This bug was found while troubleshooting a case.  When a customer restarted the queues, they noticed that all of the persistent messages in the database were gone.  I have yet to verify this and will verify as soon as possible.  I wanted to make sure that I didn't forget to put it in.  So at this point this is an unverified bug. 

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

        


From jira-events at lists.jboss.org  Wed Jul 15 01:14:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 01:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1401) Unverified:
 Restarting a Queue will delete persistent messages in the queue.
In-Reply-To: <1348241.1216341592381.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1872477410.1247634869468.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1401:
------------------------------------

      Component/s: Configuration and Management
    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> Unverified: Restarting a Queue will delete persistent messages in the queue.
> ----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1401
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1401
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.4.0.SP3
>            Reporter: Jay Howell
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Restarting a queue in a running server will delete persistent messages out of the database.  This bug was found while troubleshooting a case.  When a customer restarted the queues, they noticed that all of the persistent messages in the database were gone.  I have yet to verify this and will verify as soon as possible.  I wanted to make sure that I didn't forget to put it in.  So at this point this is an unverified bug. 

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

        


From jira-events at lists.jboss.org  Wed Jul 15 01:33:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 01:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <531380494.1247636009698.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1685:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.3.GA
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

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

        


From jira-events at lists.jboss.org  Wed Jul 15 01:33:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 01:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1435) Connection
 drop cannot recover JMSSession
In-Reply-To: <31561080.1225686021029.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1713084271.1247636009525.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476310#action_12476310 ] 

Howard Gao commented on JBMESSAGING-1435:
-----------------------------------------


Hi Chris,

To me it sounds like an JBoss ESB feature request. So probably we will reject it and you can report this to ESB team.



> Connection drop cannot recover JMSSession
> -----------------------------------------
>
>                 Key: JBMESSAGING-1435
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1435
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>         Environment: jbossesb-server-4.4.GA
> Windows XP
>            Reporter: Chris Au
>            Assignee: Tim Fox
>
> I used JMSRouter to route message to a SonicMQ, it works fine. But I just tried to figure out the exception handling method and tried to manually drop the connection from ESB Client to SonicMQ. But after I dropped the connection, exception raised as follows : 
> javax.jms.IllegalStateException: The session is closed.
> 	at progress.message.jimpl.Session.getJMSObjectClosedException(Unknown Source)
> 	at progress.message.jimpl.Session.createTextMessage(Unknown Source)
> 	at org.jboss.internal.soa.esb.rosetta.pooling.JmsSession.createTextMessage(JmsSession.java:210)
> 	at org.jboss.soa.esb.actions.routing.JMSRouter.createJMSMessageWithObjectType(JMSRouter.java:262)
> 	at org.jboss.soa.esb.actions.routing.JMSRouter.route(JMSRouter.java:232)
> 	at org.jboss.soa.esb.actions.routing.JMSRouter.process(JMSRouter.java:211)
> 	at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:316)
> 	at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:530)
> 	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)
> Is it an expected behavior that it will not do auto-retry? As I could not find any "isSessionClosed()" kind method to check if the session is closed. 
> On the other hand, I also listens to SonicMQ, the connection will automatically recover once I manually drop the connection session. Could the similar be implemented in JmsSender ?
> Another issue is......is it possible to provide any clue for the cause of the exception : 
> ERROR [org.jboss.jms.client.container.ClosedInterceptor] ClosedInterceptor.ClientSessionDelegate[ya-ie6ih2nf-1-9wwug2nf-klr89h-m4u4js4]: method getAcknowledgeMode() did not go through, the interceptor is CLOSED  ? 
> Thanks a lot.

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

        


From jira-events at lists.jboss.org  Wed Jul 15 01:38:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 01:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1436)
 MessageRedeliverer for DLQ
In-Reply-To: <30004743.1225773383675.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <422471645.1247636309233.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476311#action_12476311 ] 

Howard Gao commented on JBMESSAGING-1436:
-----------------------------------------

Hi Chris,

This should be an JBOSS ESP issue, please raise the issue against the ESB project. Thanks.


> MessageRedeliverer for DLQ
> --------------------------
>
>                 Key: JBMESSAGING-1436
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1436
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>         Environment: JBossESB-server-4.4.GA
> WindowsXP
>            Reporter: Chris Au
>            Assignee: Tim Fox
>
> I have seen the source code of MessageRedeliverer, which defaults to be resending message for RDLVR classification. But I see there shouldn't be difficult to modify so that it could support redelivery of message for DLQ. (We may want to try the DLQ once per day or even once a week automatically so as to cleanup accumulated DLQ messages).
> I also noticed that the DBMessageStoreImpl.resend function only supports for RDLVR classification because of the checking that 
> delete(uuid, RedeliverStore.CLASSIFICATION_RDLVR, con)==1 
> So even if I manually invoke the internal redeliverer service with a message having header property : 
> org.jboss.soa.esb.messagestore.classification = DLQ
> the redelivery will not success.

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

        


From jira-events at lists.jboss.org  Wed Jul 15 01:46:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 01:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1287) SOA-P test
 suite failures
In-Reply-To: <23570323.1210850002522.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <711205247.1247636789300.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476312#action_12476312 ] 

Howard Gao commented on JBMESSAGING-1287:
-----------------------------------------

Hi Aleksandar,

This jira is a little out dated, can you give some update? for example, is it still failing on your environment and what's the version of JBM are you using?

Thanks
Howard


> SOA-P test suite failures
> -------------------------
>
>                 Key: JBMESSAGING-1287
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1287
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP01
>            Reporter: Aleksandar Kostadinov
>            Assignee: Tim Fox
>
> I'm running the JBM test suite against the binaries in the SOA-P Platform 4.2 CP01. I see 4 failures. 
>     * TEST-org.jboss.test.messaging.jms.bridge.BridgeTest-Remote-bisocket.xml.
>     * org.jboss.test.messaging.jms.clustering.MultipleFailoverTest(Clustering).testFailoverFloodTwoServers
>     * org.jboss.test.messaging.jms.clustering.NoFailoverTest(Clustering).testCrashNoFailover
>     * org.jboss.test.messaging.jms.ManifestTest.testManifestEntries
> Failure details in here http://hudson.qa.jboss.com/hudson/job/jboss-soa-platform-JBM-testsuite/73/testReport/
> 3 of the failures are timeout (see console log for BridgeTest). We are running on a 2 CPU DualCore physical machine so system speed should not be an issue. 

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

        


From jira-events at lists.jboss.org  Wed Jul 15 01:48:42 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 01:48:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1287) SOA-P test
	suite failures
In-Reply-To: <23570323.1210850002522.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1619009699.1247636922213.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1287:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> SOA-P test suite failures
> -------------------------
>
>                 Key: JBMESSAGING-1287
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1287
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP01
>            Reporter: Aleksandar Kostadinov
>            Assignee: Howard Gao
>
> I'm running the JBM test suite against the binaries in the SOA-P Platform 4.2 CP01. I see 4 failures. 
>     * TEST-org.jboss.test.messaging.jms.bridge.BridgeTest-Remote-bisocket.xml.
>     * org.jboss.test.messaging.jms.clustering.MultipleFailoverTest(Clustering).testFailoverFloodTwoServers
>     * org.jboss.test.messaging.jms.clustering.NoFailoverTest(Clustering).testCrashNoFailover
>     * org.jboss.test.messaging.jms.ManifestTest.testManifestEntries
> Failure details in here http://hudson.qa.jboss.com/hudson/job/jboss-soa-platform-JBM-testsuite/73/testReport/
> 3 of the failures are timeout (see console log for BridgeTest). We are running on a 2 CPU DualCore physical machine so system speed should not be an issue. 

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

        


From jira-events at lists.jboss.org  Wed Jul 15 01:53:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 01:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1287) SOA-P test
	suite failures
In-Reply-To: <23570323.1210850002522.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1836456994.1247637209228.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1287:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> SOA-P test suite failures
> -------------------------
>
>                 Key: JBMESSAGING-1287
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1287
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP01
>            Reporter: Aleksandar Kostadinov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> I'm running the JBM test suite against the binaries in the SOA-P Platform 4.2 CP01. I see 4 failures. 
>     * TEST-org.jboss.test.messaging.jms.bridge.BridgeTest-Remote-bisocket.xml.
>     * org.jboss.test.messaging.jms.clustering.MultipleFailoverTest(Clustering).testFailoverFloodTwoServers
>     * org.jboss.test.messaging.jms.clustering.NoFailoverTest(Clustering).testCrashNoFailover
>     * org.jboss.test.messaging.jms.ManifestTest.testManifestEntries
> Failure details in here http://hudson.qa.jboss.com/hudson/job/jboss-soa-platform-JBM-testsuite/73/testReport/
> 3 of the failures are timeout (see console log for BridgeTest). We are running on a 2 CPU DualCore physical machine so system speed should not be an issue. 

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

        


From jira-events at lists.jboss.org  Wed Jul 15 01:55:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 01:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1478) inconsistent
 test suite performance
In-Reply-To: <25748306.1231170954442.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <79015774.1247637329211.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1478:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> inconsistent test suite performance
> -----------------------------------
>
>                 Key: JBMESSAGING-1478
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1478
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Tests and Performance
>    Affects Versions:  1.4.0.SP3.CP04
>            Reporter: Aleksandar Kostadinov
>            Assignee: Howard Gao
>
> I see inconsistent performance running the JBM test suite. Here I have 2 builds on the same physical machine (windows), using local disk storage so environment should be pretty stable.
> The mysql database is shared but I doubt it is the culprit. 
> I run the test suite with the following options:
> property( name: "functional.tests.database", value: dbname )
> property( name: "stress.tests.database", value: dbname )
> property( name: "clustering.tests.database", value: dbname )
> property( name: "test.target", value: "report" )
> property( name: "test.bind.address", value: properties["env.MYTESTIP_1"] )
> property( name: "jboss.messaging.groupname", value: properties["env.BUILD_TAG"])                                                                               
> property( name: "jboss.messaging.datachanneludpaddress", value: properties["env.MCAST_ADDR"] )
> property( name: "jboss.messaging.controlchanneludpaddress", value: properties["env.MCAST_ADDR"] )
> Are there any other options I can add to increase isolation from other processes in the same LAN?
> Would you be able to look at these 2 builds and based on the logs, say why is the first one taking longer and eventually timeout?
> http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/163/
> http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/164/

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

        


From jira-events at lists.jboss.org  Wed Jul 15 02:04:29 2009
From: jira-events at lists.jboss.org (Aleksandar Kostadinov (JIRA))
Date: Wed, 15 Jul 2009 02:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1287) SOA-P test
 suite failures
In-Reply-To: <23570323.1210850002522.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <381146544.1247637869280.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476316#action_12476316 ] 

Aleksandar Kostadinov commented on JBMESSAGING-1287:
----------------------------------------------------

Hallo, as I said in my previous comment the problem is that you have a file called VERSION and you use it to get your version string. So if any other library has such file, it can be read instead of yours and probably cause problems.

I'm not sure about what should be done. Two suggestions below:
1. Rename that file to JBM_VERSION or some other name that is less likely being used by some other project.
2. Verify that the deployment in SOA-P is such that this can never cause a problem. Given that JBM seems to be working in the other testing this is likely to be true. But I'm not sure if in any customer deployment scenarios this can't get them in trouble.

Hope this makes sense.

> SOA-P test suite failures
> -------------------------
>
>                 Key: JBMESSAGING-1287
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1287
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP01
>            Reporter: Aleksandar Kostadinov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> I'm running the JBM test suite against the binaries in the SOA-P Platform 4.2 CP01. I see 4 failures. 
>     * TEST-org.jboss.test.messaging.jms.bridge.BridgeTest-Remote-bisocket.xml.
>     * org.jboss.test.messaging.jms.clustering.MultipleFailoverTest(Clustering).testFailoverFloodTwoServers
>     * org.jboss.test.messaging.jms.clustering.NoFailoverTest(Clustering).testCrashNoFailover
>     * org.jboss.test.messaging.jms.ManifestTest.testManifestEntries
> Failure details in here http://hudson.qa.jboss.com/hudson/job/jboss-soa-platform-JBM-testsuite/73/testReport/
> 3 of the failures are timeout (see console log for BridgeTest). We are running on a 2 CPU DualCore physical machine so system speed should not be an issue. 

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

        


From jira-events at lists.jboss.org  Wed Jul 15 02:06:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1513) Database
 maintenance scripts
In-Reply-To: <19858050.1234906484708.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <554366462.1247637989213.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476317#action_12476317 ] 

Howard Gao commented on JBMESSAGING-1513:
-----------------------------------------

Hi Len,

Can you brief me what this script for? I had a look at SOA-310 but I don't know much about SOA project. 

Thanks.
Howard


> Database maintenance scripts
> ----------------------------
>
>                 Key: JBMESSAGING-1513
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1513
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>    Affects Versions: 1.4.2.GA.SP1
>            Reporter: Len DiMaggio
>            Assignee: Tim Fox
>
> Project JIRA for SOA-P platform JIRA: https://jira.jboss.org/jira/browse/SOA-310

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

        


From jira-events at lists.jboss.org  Wed Jul 15 02:20:30 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:20:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1594) Provide
 support for a List of Strings (in StreamMessage) with a size > 64K
In-Reply-To: <19407645.1239259282444.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1540760579.1247638830095.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1594:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> Provide support for a List of Strings (in StreamMessage) with a size > 64K
> --------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1594
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1594
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3
>            Reporter: Colin Mondesir
>            Assignee: Howard Gao
>
> Looking at the code, there is support for 'longstring' for java.lang.String. But that doesn't happen for a List of Strings.

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

        


From jira-events at lists.jboss.org  Wed Jul 15 02:20:30 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:20:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1513) Database
 maintenance scripts
In-Reply-To: <19858050.1234906484708.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <712891165.1247638830206.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1513:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA
         Assignee: Howard Gao  (was: Tim Fox)


> Database maintenance scripts
> ----------------------------
>
>                 Key: JBMESSAGING-1513
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1513
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>    Affects Versions: 1.4.2.GA.SP1
>            Reporter: Len DiMaggio
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Project JIRA for SOA-P platform JIRA: https://jira.jboss.org/jira/browse/SOA-310

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

        


From jira-events at lists.jboss.org  Wed Jul 15 02:23:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1594) Provide
 support for a List of Strings (in StreamMessage) with a size > 64K
In-Reply-To: <19407645.1239259282444.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <216924033.1247639009151.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1594:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> Provide support for a List of Strings (in StreamMessage) with a size > 64K
> --------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1594
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1594
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3
>            Reporter: Colin Mondesir
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Looking at the code, there is support for 'longstring' for java.lang.String. But that doesn't happen for a List of Strings.

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

        


From jira-events at lists.jboss.org  Wed Jul 15 02:26:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1610) expose
 jbossInternalLifecycle method on jms destination mbeans
In-Reply-To: <27082798.1240932886857.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1551577264.1247639189797.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1610:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> expose jbossInternalLifecycle method on jms destination mbeans
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-1610
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1610
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: AS Integration
>    Affects Versions: 1.4.3.GA
>            Reporter: Emanuel Muckenhuber
>            Assignee: Tim Fox
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Currently the Queue and Topic xmbean definitions don't expose the jbossInternalLifecycle(String method). This method is needed that the lifecycle and state changes of a mbean are handled by microcontainer (AS5). Otherwise profileservice cannot determine the current state and a stopped jms destination would be still exposed as running to JON/JOPR.

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

        


From jira-events at lists.jboss.org  Wed Jul 15 02:28:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1610) expose
 jbossInternalLifecycle method on jms destination mbeans
In-Reply-To: <27082798.1240932886857.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1960517372.1247639309898.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1610:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> expose jbossInternalLifecycle method on jms destination mbeans
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-1610
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1610
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: AS Integration
>    Affects Versions: 1.4.3.GA
>            Reporter: Emanuel Muckenhuber
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Currently the Queue and Topic xmbean definitions don't expose the jbossInternalLifecycle(String method). This method is needed that the lifecycle and state changes of a mbean are handled by microcontainer (AS5). Otherwise profileservice cannot determine the current state and a stopped jms destination would be still exposed as running to JON/JOPR.

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

        


From jira-events at lists.jboss.org  Wed Jul 15 02:28:29 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 15 Jul 2009 02:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-534) Maven repository
	aggregation
Message-ID: <1192295848.1247639309938.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Maven repository aggregation
----------------------------

                 Key: JBBUILD-534
                 URL: https://jira.jboss.org/jira/browse/JBBUILD-534
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven Builds
            Reporter: Thomas Diesler


There are a number of projects which have dependencies on non-jboss
maven repos (jboss-osgi is one of them)

http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235779#4235779

I believe, this issue is general enough to have proper repo aggregation 
setup somehow

Here is a link to some aggregators

http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix

Is this a way you want to move forward or should we stick with manually copying individual artefacts to the jboss repo? 
Please note, that by doing so (i.e. mvn deploy-file) you loose the original pom and hence the information on transitive dependencies.

http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html


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

        


From jira-events at lists.jboss.org  Wed Jul 15 02:30:29 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 15 Jul 2009 02:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-534) Maven repository
	aggregation
In-Reply-To: <1192295848.1247639309938.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <591807180.1247639429597.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476318#action_12476318 ] 

Thomas Diesler commented on JBBUILD-534:
----------------------------------------

Please also note, that even if you preserve the original POM on 'deploy-file' it is likely that the deployed file itself has dependencies on artefacts in other repositories.

> Maven repository aggregation
> ----------------------------
>
>                 Key: JBBUILD-534
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-534
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Thomas Diesler
>
> There are a number of projects which have dependencies on non-jboss
> maven repos (jboss-osgi is one of them)
> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235779#4235779
> I believe, this issue is general enough to have proper repo aggregation 
> setup somehow
> Here is a link to some aggregators
> http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix
> Is this a way you want to move forward or should we stick with manually copying individual artefacts to the jboss repo? 
> Please note, that by doing so (i.e. mvn deploy-file) you loose the original pom and hence the information on transitive dependencies.
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html

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

        


From jira-events at lists.jboss.org  Wed Jul 15 02:32:42 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 15 Jul 2009 02:32:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-534) Maven repository
	aggregation
In-Reply-To: <1192295848.1247639309938.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <219421027.1247639562266.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476319#action_12476319 ] 

Thomas Diesler commented on JBBUILD-534:
----------------------------------------

Max sais:

Paul G. and I are exploring to setup a Nexus repository 
manager....needed to get order in the jboss maven chaos we got right now 
;) Plus looking into
getting a similar setup for the productized binaries.

Problem right now is time and machine availability constraints - if you 
want to help out with this ping me :)


> Maven repository aggregation
> ----------------------------
>
>                 Key: JBBUILD-534
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-534
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Thomas Diesler
>
> There are a number of projects which have dependencies on non-jboss
> maven repos (jboss-osgi is one of them)
> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235779#4235779
> I believe, this issue is general enough to have proper repo aggregation 
> setup somehow
> Here is a link to some aggregators
> http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix
> Is this a way you want to move forward or should we stick with manually copying individual artefacts to the jboss repo? 
> Please note, that by doing so (i.e. mvn deploy-file) you loose the original pom and hence the information on transitive dependencies.
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html

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

        


From jira-events at lists.jboss.org  Wed Jul 15 02:45:29 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 15 Jul 2009 02:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-534) Maven repository
	aggregation
In-Reply-To: <1192295848.1247639309938.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1762110903.1247640329327.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476320#action_12476320 ] 

Thomas Diesler commented on JBBUILD-534:
----------------------------------------

Generally, I'd like to mention again that 'deploy-file' is not good  solution because of 

* with the generated POM you loose all info about transitive dependencies, etc.

* when you preserve/deploy the original POM you also deploy the dependencies on other repos

* the transitive enclosure of information for (groupId+artifactId+version+classifier) should be equal independent of the repo where you get the artifact from


> Maven repository aggregation
> ----------------------------
>
>                 Key: JBBUILD-534
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-534
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Thomas Diesler
>
> There are a number of projects which have dependencies on non-jboss
> maven repos (jboss-osgi is one of them)
> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235779#4235779
> I believe, this issue is general enough to have proper repo aggregation 
> setup somehow
> Here is a link to some aggregators
> http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix
> Is this a way you want to move forward or should we stick with manually copying individual artefacts to the jboss repo? 
> Please note, that by doing so (i.e. mvn deploy-file) you loose the original pom and hence the information on transitive dependencies.
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html

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

        


From jira-events at lists.jboss.org  Wed Jul 15 02:45:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1287) SOA-P test
 suite failures
In-Reply-To: <23570323.1210850002522.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1952057494.1247640329439.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476321#action_12476321 ] 

Howard Gao commented on JBMESSAGING-1287:
-----------------------------------------

Hi Aleksandar,

Thanks. Now I understand the issue. I think suggestion 1 is a good option.

Howard


> SOA-P test suite failures
> -------------------------
>
>                 Key: JBMESSAGING-1287
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1287
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP01
>            Reporter: Aleksandar Kostadinov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> I'm running the JBM test suite against the binaries in the SOA-P Platform 4.2 CP01. I see 4 failures. 
>     * TEST-org.jboss.test.messaging.jms.bridge.BridgeTest-Remote-bisocket.xml.
>     * org.jboss.test.messaging.jms.clustering.MultipleFailoverTest(Clustering).testFailoverFloodTwoServers
>     * org.jboss.test.messaging.jms.clustering.NoFailoverTest(Clustering).testCrashNoFailover
>     * org.jboss.test.messaging.jms.ManifestTest.testManifestEntries
> Failure details in here http://hudson.qa.jboss.com/hudson/job/jboss-soa-platform-JBM-testsuite/73/testReport/
> 3 of the failures are timeout (see console log for BridgeTest). We are running on a 2 CPU DualCore physical machine so system speed should not be an issue. 

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

        


From jira-events at lists.jboss.org  Wed Jul 15 02:50:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1619) add example
 TCP cluster configuration
In-Reply-To: <8236548.1241645807005.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1083143809.1247640629342.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1619:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA
         Assignee: Howard Gao  (was: Jimmy Wilson)


> add example TCP cluster configuration
> -------------------------------------
>
>                 Key: JBMESSAGING-1619
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1619
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Dennis Reed
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Add an example TCP cluster configuration (commented out) to all the example *-persistence-service.xml files.
> This will make it easier for users who have issues with UDP multicast to configure it to use TCP clustering.
> (The same thing is being done to all the EAP configurations that don't already include this). 

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

        


From jira-events at lists.jboss.org  Wed Jul 15 02:52:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1621) Provide
 complete message ordering in a clustered environment
In-Reply-To: <16554562.1242110266630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1303763371.1247640749261.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1621:
------------------------------------

          Component/s: JMS Clustering
        Fix Version/s: 1.4.0.SP3.CP09
                       1.4.5.GA
    Affects Version/s: 1.4.4.GA
                       1.4.0.SP3.CP08


Put this on-hold untill there is a strong need. Otherwise we encourage users to move to JBM 2.0

> Provide complete message ordering in a clustered environment
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1621
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1621
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Yusuke Yamamoto
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> While JBMESSAGING-1416 states message ordering feature in a singleton configuration, customer is also requesting a complete message ordering feature which is applicable in a clustered environment.
> Here's the background:
> In the case JMS is used, both performance and scalability are priority.
> There is a conflict between scalable JMS implementation and complete message ordering feature since order aware messages cannot be processed concurrently.
> But order unaware queues should be still processed in parallel for better throughput.
> Additionally, there are some cases that no downtime is acceptable. But HA-Singleton requires certain amount of time to fail-over the service to other node.

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

        


From jira-events at lists.jboss.org  Wed Jul 15 02:52:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1676) Jboss
	Messaging deadlock
In-Reply-To: <317741887.1246538691801.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <271856674.1247640749373.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1676:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA
         Assignee: Howard Gao  (was: Tim Fox)


> Jboss Messaging deadlock
> ------------------------
>
>                 Key: JBMESSAGING-1676
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1676
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: AS Integration
>    Affects Versions: 1.4.3.GA
>         Environment: Version:Linux 2.6.18-53.el5
> Description:Linux Operating System
> Traits
> OS Name: Linux
> OS Version: 2.6.18-53.el5
> Architecture: i386
> Distribution Name: CentOS
> Distribution Version: release 5 (Final)
>            Reporter: Daniel Cullender
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Under high concurrent load it appears that jboss messaging gets stuck in the Hashmap.put method which causes the threads to deadlock which in turn causes transaction timeouts.
> We have several mdb's which have max session sizes of 150, we have max strict pool size of 150 and the jboss thread pool size of 50.
> Recently upgraded from jboss AS 4 MQ series to jboss 5 AS with jboss messaging 1.4.3.GA, with JbossMQ  this problem did not occur.
> The stack trace of the problem is as follows :
> Thread: WorkManager(2)-50 : priority:5, demon:true, threadId:147,
> threadState:RUNNABLE
> java.util.HashMap.put(HashMap.java:374)
> java.util.HashSet.add(HashSet.java:200)
> org.jboss.jms.client.state.HierarchicalStateSupport.(HierarchicalStateSupport.java:63)
> org.jboss.jms.client.state.ProducerState.(ProducerState.java:68)
> org.jboss.jms.client.container.StateCreationAspect.handleCreateProducerDelegate(StateCreationAspect.java:180)
> org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateProducerDelegate_30485827.invoke(StateCreationAspect_z_handleCreateProducerDelegate_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.delegate.ClientSessionDelegate.createProducerDelegate(ClientSessionDelegate.java)
> org.jboss.jms.client.JBossSession.createProducer(JBossSession.java:209)
> qut.common.dao.JmsDao.publishMessage(JmsDao.java:66)
> qut.common.dao.JmsDao.publish(JmsDao.java:104)
> qut.order.manager.OrderManagerMBean.publish(OrderManagerMBean.java:156)
> qut.order.manager.OrderManagerMBean.process(OrderManagerMBean.java:98)
> sun.reflect.GeneratedMethodAccessor354.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
> sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
> org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:451)
> org.jboss.ejb3.service.ServiceMBeanDelegate.invoke(ServiceMBeanDelegate.java:215)
> org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> $Proxy1543.process(Unknown Source)
> qut.order.mdb.OrderManagerTradingDataMDBean.onMessage(OrderManagerTradingDataMDBean.java:64)
> sun.reflect.GeneratedMethodAccessor353.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor$InvocationContext.proceed(InvocationContextInterceptor.java:138)
> qut.common.interceptor.ConcurrencyInterceptor.myInterceptor(ConcurrencyInterceptor.java:46)
> sun.reflect.GeneratedMethodAccessor320.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:83)
> org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:70)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:59)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
> sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
> org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:80)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:282)
> org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:270)
> org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:140)
> $Proxy389.onMessage(Unknown Source)
> org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:178)
> org.jboss.jms.client.container.ClientConsumer.callOnMessageStatic(ClientConsumer.java:160)
> org.jboss.jms.client.container.SessionAspect.handleRun(SessionAspect.java:831)
> org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleRun_30485827.invoke(SessionAspect_z_handleRun_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.delegate.ClientSessionDelegate.run(ClientSessionDelegate.java)
> org.jboss.jms.client.JBossSession.run(JBossSession.java:199)
> org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:234)
> org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205)
> org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> java.lang.Thread.run(Thread.java:619)
> Locked synchronizers : 
> - locked <0x535d1e> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> Thread: WorkManager(2)-70 : priority:5, demon:true, threadId:168,
> threadState:RUNNABLE
> java.util.HashMap.put(HashMap.java:374)
> java.util.HashSet.add(HashSet.java:200)
> org.jboss.jms.client.state.HierarchicalStateSupport.(HierarchicalStateSupport.java:63)
> org.jboss.jms.client.state.ProducerState.(ProducerState.java:68)
> org.jboss.jms.client.container.StateCreationAspect.handleCreateProducerDelegate(StateCreationAspect.java:180)
> org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateProducerDelegate_30485827.invoke(StateCreationAspect_z_handleCreateProducerDelegate_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.delegate.ClientSessionDelegate.createProducerDelegate(ClientSessionDelegate.java)
> org.jboss.jms.client.JBossSession.createProducer(JBossSession.java:209)
> qut.common.dao.JmsDao.publishMessage(JmsDao.java:66)
> qut.common.dao.JmsDao.publish(JmsDao.java:104)
> qut.order.manager.OrderManagerMBean.publish(OrderManagerMBean.java:156)
> qut.order.manager.OrderManagerMBean.process(OrderManagerMBean.java:98)
> sun.reflect.GeneratedMethodAccessor354.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
> sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
> org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:451)
> org.jboss.ejb3.service.ServiceMBeanDelegate.invoke(ServiceMBeanDelegate.java:215)
> org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> $Proxy1384.process(Unknown Source)
> qut.order.mdb.OrderManagerTradingDataMDBean.onMessage(OrderManagerTradingDataMDBean.java:64)
> sun.reflect.GeneratedMethodAccessor353.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor$InvocationContext.proceed(InvocationContextInterceptor.java:138)
> qut.common.interceptor.ConcurrencyInterceptor.myInterceptor(ConcurrencyInterceptor.java:46)
> sun.reflect.GeneratedMethodAccessor320.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:83)
> org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:70)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:59)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
> sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
> org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:80)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:282)
> org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:270)
> org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:140)
> $Proxy389.onMessage(Unknown Source)
> org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:178)
> org.jboss.jms.client.container.ClientConsumer.callOnMessageStatic(ClientConsumer.java:160)
> org.jboss.jms.client.container.SessionAspect.handleRun(SessionAspect.java:831)
> org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleRun_30485827.invoke(SessionAspect_z_handleRun_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.delegate.ClientSessionDelegate.run(ClientSessionDelegate.java)
> org.jboss.jms.client.JBossSession.run(JBossSession.java:199)
> org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:234)
> org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205)
> org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> java.lang.Thread.run(Thread.java:619)
> Locked synchronizers : 
> - locked <0x18827b6> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

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

        


From jira-events at lists.jboss.org  Wed Jul 15 02:58:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1461) Number of
 relivery attempts does not match with my settings
In-Reply-To: <4356892.1227708100133.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1985062978.1247641109431.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1461:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA
         Assignee: Howard Gao  (was: Tim Fox)


> Number of relivery attempts does not match with my settings
> -----------------------------------------------------------
>
>                 Key: JBMESSAGING-1461
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1461
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.SP4
>         Environment: JBoss 4.0.4.GA
> Windows server 2003
>            Reporter: Nicolas Laporte
>            Assignee: Howard Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> I set <attribute name="MaxDeliveryAttempts">15</attribute>
> The time-to-live parameter used by the client is 1 hour.
> We call the setRollbackOnly() method of our CMT MDB if an recoverable exception occurrs.
> The number of redelivery is 5. I expected 15.
> Could you tell me if this problem is known and if it is fixed in an upper version ?
> Thanks a lot for your support.
> Nicolas Laporte
> PDF Solutions

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

        


From jira-events at lists.jboss.org  Wed Jul 15 03:02:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 03:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1615) Programmatic
 way to check the state of a topic
In-Reply-To: <22443752.1241518126593.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1943913816.1247641349227.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1615:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> Programmatic way to check the state of a topic
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1615
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1615
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 1.4.1.GA
>            Reporter: Colin Mondesir
>            Assignee: Howard Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When the deployTopic(String, String) method is called we have found there is a slight delay before the topic is available to create MessageConsumer.
> Is there a programmatic way of checking the state that the topic is in, so that we don't have to wait an arbitrary period of time before creating the Consumer?

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

        


From jira-events at lists.jboss.org  Wed Jul 15 03:04:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 03:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1684) Message
 remain in the queue and do not get dispatched
In-Reply-To: <1603937672.1247553629290.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1090026785.1247641469438.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1684:
------------------------------------

          Component/s: JMS Facade
        Fix Version/s: 1.4.0.SP3.CP09
                       1.4.5.GA
    Affects Version/s: 1.4.3.GA


> Message remain in the queue and do not get dispatched
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1684
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1684
>             Project: JBoss Messaging
>          Issue Type: Quality Risk
>          Components: JMS Facade
>    Affects Versions: 1.4.3.GA
>         Environment: SuSe Linux Enterprise Server 10, Java 1.5.0_11, AS 5 with JBoss Messaging - default installation
>            Reporter: Alexander Marktl
>            Assignee: Howard Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: jms-provider-evaluation.zip
>
>
> I tried to create 10 queues and send 10.000 messages per queue from a single producer per queue to a single consumer per queue. Unfortunately  not all of the messages where delivered, some messages remain in the queues and wait for delivery. The JMX console for example states: 3 messages in the queue, 3 messages pending for delivery. But nothing happens. My receivers don't get these last messages. I don't know if this is a configuration issue or a bug. 
> The queues are named: qname_0 ...qname_n

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

        


From jira-events at lists.jboss.org  Wed Jul 15 03:04:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 03:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1490) BridgeService
 should be JAAS aware
In-Reply-To: <12562631.1232152144349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1487451183.1247641469635.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1490:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> BridgeService should be JAAS aware
> ----------------------------------
>
>                 Key: JBMESSAGING-1490
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1490
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 1.4.2.GA
>         Environment: n/a
>            Reporter: Nicholas Sayer
>            Assignee: Howard Gao
>            Priority: Optional
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> org.jboss.jms.server.bridge.BridgeService currently requires a username and password for the source and destination. It would be better if it could be configured with a JAAS login context name. This would allow username and password information to be set in, for example, a SecureIdentityLoginModule. For example:
>     <application-policy name = "JmsBridgeRealm">
>        <authentication>
>           <login-module code = "org.jboss.resource.security.SecureIdentityLoginModule" flag = "required">
>              <module-option name = "principal">${bridge.user}</module-option>
>              <module-option name = "userName">${bridge.user}</module-option>
>              <module-option name = "password">${bridge.encryptedPassword}</module-option>
>              <module-option name = "ignoreMissigingMCF">true</module-option>
> <!-- it is a separate bug that you must set managedConnectionFactoryName to something regardless of setting ignoreMissingMCF to true -->
>              <module-option name = "managedConnectionFactoryName">jboss.nonexistent:service=NonExistent,name=NonExistent</module-option>
>           </login-module>
>        </authentication>
>     </application-policy>
> There is undoubtedly a better way to accomplish this (probably to pass the JAAS context directly into the JMS connection factory used to vend connections for the bridge), but we're using this as a crude hack for now:
> import java.util.Set;
> import javax.security.auth.Subject;
> import javax.security.auth.login.LoginContext;
> import javax.security.auth.login.LoginException;
> import javax.security.auth.login.CredentialNotFoundException;
> import javax.resource.spi.security.PasswordCredential;
> import org.jboss.jms.server.bridge.BridgeService;
> public class JAASAwareBridgeService extends BridgeService {
>         private String sourceContext, targetContext;
>         public void setSourceLoginContext(String ctxName) { this.sourceContext = ctxName; }
>         public String getSourceLoginContext() { return this.sourceContext; }
>         public void setTargetLoginContext(String ctxName) { this.targetContext = ctxName; }
>         public String getTargetLoginContext() { return this.targetContext; }
>         public void start() throws Exception {
>                 setupSourceCredentials();
>                 setupTargetCredentials();
>                 super.start();
>         }
>         private void setupSourceCredentials() throws LoginException {
>                 PasswordCredential pc = getPasswordCredential(this.sourceContext);
>                 super.setSourceUsername(pc.getUserName());
>                 super.setSourcePassword(new String(pc.getPassword()));
>          }
>         private void setupTargetCredentials() throws LoginException {
>                 PasswordCredential pc = getPasswordCredential(this.targetContext);
>                 super.setTargetUsername(pc.getUserName());
>                 super.setTargetPassword(new String(pc.getPassword()));
>         }
>         private static PasswordCredential getPasswordCredential(String contextName) throws LoginException {
>                 LoginContext ctx = new LoginContext(contextName);
>                 ctx.login();
>                 Subject s = ctx.getSubject();
>                 Set<PasswordCredential> creds = s.getPrivateCredentials(PasswordCredential.class);
>                 if (creds.isEmpty())
>                         throw new CredentialNotFoundException("Login context '" + contextName + "' subject has no PasswordCredential");
>                 return creds.iterator().next(); // get 1st
>         }
> }

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

        


From jira-events at lists.jboss.org  Wed Jul 15 03:13:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 03:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1478) inconsistent
 test suite performance
In-Reply-To: <25748306.1231170954442.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1896648838.1247642009415.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1478:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09


> inconsistent test suite performance
> -----------------------------------
>
>                 Key: JBMESSAGING-1478
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1478
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Tests and Performance
>    Affects Versions:  1.4.0.SP3.CP04
>            Reporter: Aleksandar Kostadinov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09
>
>
> I see inconsistent performance running the JBM test suite. Here I have 2 builds on the same physical machine (windows), using local disk storage so environment should be pretty stable.
> The mysql database is shared but I doubt it is the culprit. 
> I run the test suite with the following options:
> property( name: "functional.tests.database", value: dbname )
> property( name: "stress.tests.database", value: dbname )
> property( name: "clustering.tests.database", value: dbname )
> property( name: "test.target", value: "report" )
> property( name: "test.bind.address", value: properties["env.MYTESTIP_1"] )
> property( name: "jboss.messaging.groupname", value: properties["env.BUILD_TAG"])                                                                               
> property( name: "jboss.messaging.datachanneludpaddress", value: properties["env.MCAST_ADDR"] )
> property( name: "jboss.messaging.controlchanneludpaddress", value: properties["env.MCAST_ADDR"] )
> Are there any other options I can add to increase isolation from other processes in the same LAN?
> Would you be able to look at these 2 builds and based on the logs, say why is the first one taking longer and eventually timeout?
> http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/163/
> http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/164/

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

        


From jira-events at lists.jboss.org  Wed Jul 15 03:30:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 15 Jul 2009 03:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-359) Events attached to
	activities
Message-ID: <1291966959.1247643029123.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Events attached to activities 
------------------------------

                 Key: GPD-359
                 URL: https://jira.jboss.org/jira/browse/GPD-359
             Project: JBoss jBPM GPD
          Issue Type: Feature Request
            Reporter: Koen Aers
            Assignee: Koen Aers
             Fix For: jBPM jPDL Designer 4.x




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

        


From jira-events at lists.jboss.org  Wed Jul 15 04:08:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 15 Jul 2009 04:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-360) Refine wire object
	configuration
Message-ID: <1475697551.1247645309386.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Refine wire object configuration
--------------------------------

                 Key: GPD-360
                 URL: https://jira.jboss.org/jira/browse/GPD-360
             Project: JBoss jBPM GPD
          Issue Type: Feature Request
            Reporter: Koen Aers
            Assignee: Koen Aers
             Fix For: jBPM jPDL Designer 4.x




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

        


From jira-events at lists.jboss.org  Wed Jul 15 05:06:29 2009
From: jira-events at lists.jboss.org (Jaroslaw Kijanowski (JIRA))
Date: Wed, 15 Jul 2009 05:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2208) Agenda-group not
 picked up in decision table
Message-ID: <696057078.1247648789217.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Agenda-group not picked up in decision table
--------------------------------------------

                 Key: JBRULES-2208
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2208
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-decisiontables
    Affects Versions: 5.0.1.FINAL
            Reporter: Jaroslaw Kijanowski
            Assignee: Michael Neale


The class drools-decisiontables/src/main/java/org/drools/decisiontable/parser/DefaultRuleSheetListener
is missing AGENDAGROUP in the nextDataCell method.

Attaching patch.

This test class
drools-decisiontables/src/test/java/org/drools/decisiontable/parser/ActionTypeTest.java
could be also extended to verify the AGENDAGROUP keyword.

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

        


From jira-events at lists.jboss.org  Wed Jul 15 05:08:29 2009
From: jira-events at lists.jboss.org (Jaroslaw Kijanowski (JIRA))
Date: Wed, 15 Jul 2009 05:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2208) Agenda-group not
 picked up in decision table
In-Reply-To: <696057078.1247648789217.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <367430244.1247648909226.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jaroslaw Kijanowski updated JBRULES-2208:
-----------------------------------------

    Attachment: patch


> Agenda-group not picked up in decision table
> --------------------------------------------
>
>                 Key: JBRULES-2208
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2208
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-decisiontables
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Jaroslaw Kijanowski
>            Assignee: Michael Neale
>         Attachments: patch
>
>
> The class drools-decisiontables/src/main/java/org/drools/decisiontable/parser/DefaultRuleSheetListener
> is missing AGENDAGROUP in the nextDataCell method.
> Attaching patch.
> This test class
> drools-decisiontables/src/test/java/org/drools/decisiontable/parser/ActionTypeTest.java
> could be also extended to verify the AGENDAGROUP keyword.

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

        


From jira-events at lists.jboss.org  Wed Jul 15 05:29:41 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 15 Jul 2009 05:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <748360419.1247650181023.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved EJBTHREE-1852.
-------------------------------------

    Resolution: Done


See JBPAPP-2262

> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>            Assignee: Carlo de Wolf
>             Fix For: 1.1.8
>
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

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

        


From jira-events at lists.jboss.org  Wed Jul 15 05:29:40 2009
From: jira-events at lists.jboss.org (Bernard de Terwangne (JIRA))
Date: Wed, 15 Jul 2009 05:29:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2356) It is
 impossible to use html forms in portlets or js to build http request
In-Reply-To: <10202950.1238084123266.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <618037085.1247650180775.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476342#action_12476342 ] 

Bernard de Terwangne commented on JBPORTAL-2356:
------------------------------------------------

Thomas,

I'm getting back to you on this issue. My client just does want a full portal and prefers a simple portlet container. For now I'm providing JBPC with the attached fix. I see that the fix is not included in JBPC source code neither on the trunk or in tag 2.0.7. Can I have some hope that it would be included in a future version ?

On the other hand the comment in ControllerRequestFactory.java states that : 

/**
 * A factory that provides a way to create ControllerRequest. This factory is just a default implementation and is not
 * an authority which means that any client of the controller framework is free to determine how a controller request is
 * created.
 *
 * @author <a href="mailto:julien at jboss.org">Julien Viet</a>
 * @version $Revision: 630 $
 */

This is true only if you assume that my client provided implementation of the factory has the same fully qualified name. Indeed is instanciated in several places in the source code (ControllerFilter, PortalServlet, TCKServlet) always this way :

ControllerRequestFactory factory = new ControllerRequestFactory(context.getPageNavigationalStateSerialization());

So the only method for providing an alternative application as suggested by Julien Viet in its comment is to replace the class file. No possible configuration of the class name is provided or so. This is why it would be great to have my fix incorporated in a future version.

Bernard

> It is impossible to use html forms in portlets or js to build http request
> --------------------------------------------------------------------------
>
>                 Key: JBPORTAL-2356
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2356
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: Portlet-2.0.1
>         Environment: Linux, Java 5, Tomcat, JBoss Portlet Container 2.0
>            Reporter: Bernard de Terwangne
>         Attachments: ControllerRequestFactory.java, ControllerRequestFactory.java, ControllerRequestFactoryTestCase.java
>
>
> JBoss Portlet container conforms to the spec so well that it becomes unusable. It is impossible to query the end-user for a value and pass that value in processAction or serveResource calls. Let's say you write this in your JSP page :
> <form action="<portlet:actionURL><portlet:param name='q' value='yop'/></portlet:actionURL">
> <input name="q" type="text/>
> <input type="submit"/>
> </form>
> and in the Java code
> 	public void processAction(ActionRequest req, ActionResponse res)
> 			throws IOException, PortletException {
> 		System.out.println(req.getParameter("q");
>         }
> The printed value will allways be "yop" (the value placed in the portlet:param tag. There is no way to retrieve the value actually typed by the end user.
> This is due to the fact JBoss Portlet container mangles in Base64 the parameters from <portlet:param> and disregards parameters appended by the browser's form implementation. Same thing with <resourceURL>. There is no way to pass user input to the portlet's Java code.

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

        


From jira-events at lists.jboss.org  Wed Jul 15 06:39:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Wed, 15 Jul 2009 06:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <829376347.1247654369258.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476353#action_12476353 ] 

Ales Justin commented on JBAS-7032:
-----------------------------------

>> I have found that an EAR which includes SEAM/RF library jars in the EAR/lib directory *without* a jboss-app.xml 

With any Seam app proper isolation *must* always be enforced,
otherwise Seam cannot work properly as its architecture depends on cl isolation.
e.g. Component::getComponent(name), static usage to get component from anywhere

WebBeans used to work the same way, but this prevented to be properly used inside OSGi based kernel/container.
Hence a different approach was used, scope/components per classloader hidden in a proper abstraction.

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-app.xml, PrintResourcePathContextListener.class, PrintResourcePathContextListener.java, WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

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

        


From jira-events at lists.jboss.org  Wed Jul 15 07:15:29 2009
From: jira-events at lists.jboss.org (Vicky Kak (JIRA))
Date: Wed, 15 Jul 2009 07:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
In-Reply-To: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1260277230.1247656529612.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476360#action_12476360 ] 

Vicky Kak commented on JBAS-7086:
---------------------------------

I did perform some simple tests but did not get the 
************************************************************************
<%@ page import="javax.naming.*, javax.sql.*, javax.transaction.*,java.sql.*" %>
<%
   InitialContext context = new InitialContext();
   UserTransaction utx = (UserTransaction)context.lookup("UserTransaction");
   utx.begin();
   out.println("Started Transaction <br>");
   DataSource ds = (DataSource)context.lookup("OraDSXA");
   Connection con = ds.getConnection();
   out.println("Enlisted first Connection in TX <br>");
   Statement stmt = con.createStatement();
   out.println("Executing SQL :::: <br>");
   ResultSet rs = stmt.executeQuery("select * from tab");
   while(rs.next())
   out.println(rs.getString(1)+"<br>");
   out.println("Executing SQL Done :::: <br>");

   DataSource ds1 = (DataSource)context.lookup("OraGCDDSXA");
   Connection con1 = ds1.getConnection();
   out.println("Enlisted second Connection in TX <br>");
   Statement stmt1 = con1.createStatement();
   out.println("Executing SQL :::: <br>");
   ResultSet rs1 = stmt1.executeQuery("select * from tab");
   while(rs1.next())
   out.println(rs1.getString(1)+"<br>");
   out.println("Executing SQL Done:::: <br>");
   con1.close();

   con.close();
   utx.commit();
   out.println("Trasaction Completed !!!! <br>");

%>
************************************************************************

The -ds.xml content goes here
************************************************************************
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<xa-datasource>
     <jndi-name>OraDSXA</jndi-name>
     <use-java-context>false</use-java-context>
       <set-tx-query-timeout/>
     <track-connection-by-tx/>
     <isSameRM-override-value>false</isSameRM-override-value>
     <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
     <xa-datasource-property name="URL">jdbc:oracle:thin:@localhost:1521</xa-datasource-property>
     <xa-datasource-property name="User">scott</xa-datasource-property>
     <xa-datasource-property name="Password">tiger</xa-datasource-property>
     <!-- xa-datasource-property name="URL">jdbc:oracle:thin:@kevbates.sebtown.com:1522:SONATADB</xa-datasource-property>
     <xa-datasource-property name="User">OS1</xa-datasource-property>
     <xa-datasource-property name="Password">os1</xa-datasource-property -->
     <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
     <no-tx-separate-pools/>
     <metadata>
     <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
         <type-mapping>Oracle9i</type-mapping>
     </metadata>
 </xa-datasource>
</datasources>

<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<xa-datasource>
     <jndi-name>OraGCDDSXA</jndi-name>
     <use-java-context>false</use-java-context>
       <set-tx-query-timeout/>
     <track-connection-by-tx/>
     <isSameRM-override-value>false</isSameRM-override-value>
     <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
     <xa-datasource-property name="URL">jdbc:oracle:thin:@localhost:1521</xa-datasource-property>
     <xa-datasource-property name="User">scott</xa-datasource-property>
     <xa-datasource-property name="Password">tiger</xa-datasource-property>
     <!-- xa-datasource-property name="URL">jdbc:oracle:thin:@kevbates.sebtown.com:1522:SONATADB</xa-datasource-property>
     <xa-datasource-property name="User">GCD</xa-datasource-property>
     <xa-datasource-property name="Password">gcd</xa-datasource-property -->
     <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
     <no-tx-separate-pools/>
     <metadata>
     <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
         <type-mapping>Oracle9i</type-mapping>
     </metadata>
 </xa-datasource>
</datasources>
************************************************************************

I did test it on jboss-4.2.1.GA and on Jboss5.0.1 GA, the jsp works fine when I execute it in the Jboss4.* and it fails with following error in Jboss5
************************************************************************
15:48:25,785 WARN  [loggerI18N] [com.arjuna.ats.internal.jta.transaction.arjunacore.xastart] [com.arjuna.ats.internal.jta.transaction.arjunacore.xastart] TransactionImple.enlistResource - xa_start  - caught: XAException.XA_RETRY for < 131075, 27, 25, 494555102484848484849585756101495852975399539850505854505510248484848484958575610149585297539953985050585452 >
************************************************************************ 

> Can't enlist in transaction with second Oracle XA connection/resource.
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7086
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager (Arjuna)
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: The operating system has been windows, but that doesn't appear to be related.
> Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
>            Reporter: Kevin Bates
>            Assignee: Jesper Pedersen
>
> We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.
> At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:
> 2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
> oracle.jdbc.xa.OracleXAException
> 	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
> 	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
> 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
> com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
> 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
> 	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
> 	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
> 	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:404)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy134.executeChanges(Unknown Source)
> 	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:378)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy135.executeChanges(Unknown Source)
> 	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
> 	at java.security.AccessController.doPrivileged(AccessController.java:284)
> 	at javax.security.auth.Subject.doAs(Subject.java:573)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
> 	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
> 	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:735)
> Caused by: 
> org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
> 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 	... 90 more
> Caused by: 
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 	... 92 more
> Caused by: 
> javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	... 96 more
> The two XA data sources are configured as follows:
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">OS1</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraGCDDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">GCD</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.
> Kind regards.

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

        


From jira-events at lists.jboss.org  Wed Jul 15 07:30:42 2009
From: jira-events at lists.jboss.org (Dmitri Voronov (JIRA))
Date: Wed, 15 Jul 2009 07:30:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
In-Reply-To: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <567590353.1247657442127.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476362#action_12476362 ] 

Dmitri Voronov commented on JBAS-7086:
--------------------------------------

I have the same problem with JBoss EAP 5.0 Alpha and Oracle 9. But with the version AS 5.1.0.GA the same case works fine.

> Can't enlist in transaction with second Oracle XA connection/resource.
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7086
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager (Arjuna)
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: The operating system has been windows, but that doesn't appear to be related.
> Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
>            Reporter: Kevin Bates
>            Assignee: Jesper Pedersen
>
> We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.
> At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:
> 2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
> oracle.jdbc.xa.OracleXAException
> 	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
> 	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
> 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
> com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
> 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
> 	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
> 	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
> 	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:404)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy134.executeChanges(Unknown Source)
> 	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:378)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy135.executeChanges(Unknown Source)
> 	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
> 	at java.security.AccessController.doPrivileged(AccessController.java:284)
> 	at javax.security.auth.Subject.doAs(Subject.java:573)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
> 	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
> 	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:735)
> Caused by: 
> org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
> 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 	... 90 more
> Caused by: 
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 	... 92 more
> Caused by: 
> javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	... 96 more
> The two XA data sources are configured as follows:
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">OS1</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraGCDDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">GCD</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.
> Kind regards.

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

        


From jira-events at lists.jboss.org  Wed Jul 15 07:43:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Wed, 15 Jul 2009 07:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7097) Stack overflow
 error when establishing secured connection to Profile Service
Message-ID: <503635007.1247658209433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476363#action_12476363 ] 

Lukas Krejci commented on JBAS-7097:
------------------------------------

I've updated the ejb-client to try and replicate it (Jopr rev910) but everything seems to work correctly with JBPAPP_5_0 revision 91282. The JON server seems to connect OK now as well.

> Stack overflow error when establishing secured connection to Profile Service
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7097
>             Project: JBoss Application Server
>          Issue Type: Bug
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Jopr rev902, AS5 EAP rev91190
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The stack overflow occurs in Jopr AS5 plugin AbstractProfileServiceConnection.init() after the connection has been established.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
>         at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
> Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
>         at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
>         at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
>         ... 12 more                                                                                                                                                                       
> Caused by: java.lang.StackOverflowError                                                                                                                                                   
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
> ....                                                                           
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
>         ... 18 more                                                                                                                                                                       

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

        


From jira-events at lists.jboss.org  Wed Jul 15 08:03:47 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 15 Jul 2009 08:03:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1505) Optimise
 multiple message selectors on a queue
In-Reply-To: <5128840.1234454804372.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <263700000.1247659427720.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1505.
------------------------------------

    Resolution: Done


fixed in the trunk

> Optimise multiple message selectors on a queue
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1505
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1505
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> In the case where there are multiple message selectors on a queue, the entire queue needs to be scanned for each delivery.
> We can optimise this by adding indexes on the queue.

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

        


From jira-events at lists.jboss.org  Wed Jul 15 08:05:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 15 Jul 2009 08:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1533) Use boolean
 flag for enable grouping on distributor
In-Reply-To: <19593928.1236102863103.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <780355931.1247659529192.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1533.
------------------------------------

    Resolution: Out of Date


with JBMESSAGING-1505: grouping no longer needs to be configured by setting a special Distributor implementation

> Use boolean flag for enable grouping on distributor
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1533
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1533
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Right need to specify classname when enabling grouping on distributor - this should be a boolean flag

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

        


From jira-events at lists.jboss.org  Wed Jul 15 08:08:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 15 Jul 2009 08:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1673) MBean
 operations which
 requires a filter should treat an empty string as a null filter
In-Reply-To: <9927505.1246276136505.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1579169149.1247659709278.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1673.
------------------------------------

    Resolution: Done


fixed in the trunk

> MBean operations which requires a filter should treat an empty string as a null filter
> --------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1673
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1673
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 2.0.0.beta3
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> e.g. listMessages requires a filter parameter.
> Currently if an empty string is passed, it'll raise an exception when a filter is created from this string.
> Instead the MBean should check if the parameter is null or an empty string and treat it as a null filter.

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

        


From jira-events at lists.jboss.org  Wed Jul 15 08:31:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 15 Jul 2009 08:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1616) Classpath
 issue with file version.properties
In-Reply-To: <7671035.1241530427144.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <956324910.1247661089219.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1616.
------------------------------------

    Resolution: Done


fixed in the trunk by renaming version.properties to jboss-messaging-version.properties

> Classpath issue with file version.properties
> --------------------------------------------
>
>                 Key: JBMESSAGING-1616
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1616
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Alpha
>            Reporter: Markus Probst
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> In class org.jboss.messaging.util.VersionLoader the static method "load" throws a NumberFormatException while trying to read properties from file version.properties, if several files with this name are situated in current classpath and the "wrong" one is picked up:
> "
> java.lang.NumberFormatException: null
> at java.lang.Integer.parseInt(Integer.java:415)
> at java.lang.Integer.valueOf(Integer.java:553)
> at org.jboss.messaging.util.VersionLoader.load(VersionLoader.java:50)
> at org.jboss.messaging.core.client.impl.ClientConnectionFactoryImpl.createConnection(ClientConnectionFactoryImpl.java:135)
> at org.jboss.messaging.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:255)
> at org.jboss.messaging.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:134)
> ...
> "
> It is very likely that more than one library/artifacts contains a file called "version.properties", so I think the right way should be to rename this file to a more JBoss Messaging specific one.

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

        


From jira-events at lists.jboss.org  Wed Jul 15 09:33:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 15 Jul 2009 09:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1575) Add test for
 message size in selector and remove message id
In-Reply-To: <21091103.1239019103234.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <962012828.1247664809573.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1575.
------------------------------------

    Resolution: Done
      Assignee: Jeff Mesnil  (was: Tim Fox)


fixed in the trunk

> Add test for message size in selector and remove message id
> -----------------------------------------------------------
>
>                 Key: JBMESSAGING-1575
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1575
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> Add a selector test for message size, and remove message id from being used in selector expressions - it is not useful.

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

        


From jira-events at lists.jboss.org  Wed Jul 15 10:29:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 15 Jul 2009 10:29:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBRULES-2202) Generated types
 should be Serializable
In-Reply-To: <1963762277.1247174669126.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1895821848.1247668169359.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reopened JBRULES-2202:
------------------------------------



MVELAccumulateFunctionExecutor still requires facts to be serializable. This should not be mandatory.

> Generated types should be Serializable
> --------------------------------------
>
>                 Key: JBRULES-2202
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2202
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler, drools-core
>    Affects Versions: 5.0.0.FINAL, 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> Hello,
> Recently I've been working with Drools version 5.0.1 to set up an event processor.  While doing so I have come
> across difficulties with the accumulate function, in that it will always throw a ClassCastException
> when inserting events that are declared within my drl file.  To illustrate this I've set up an example which is
> shown below.  I've search Google and the mailing list for several hours, but the only way past this problem
> appears to be that I will have to declare a class externally and make sure it implements Serializable.  Does
> anyone has suggestions for another approach?  Secondly, I would have assumed that since Drools was
> compiling these internally declared classes, that Serializable would have been implemented automatically.  So
> is this a result of the generated class not implementing Serializable, or have I missed something in my rules
> file?  Thanks.
> The important part of my drl file is:
> declare TestEvent
>    @role( event )
>    @expires(10s)
>    id : String
> end
> #This rule works fine when 'Accumulate Count' is commented out, and is used to make
> #sure that the event inserting has worked.
> rule "Is It There"
>     when
>         TestEvent() from entry-point "test"
>     then
>         System.out.println("Found a TestEvent.");
> end
> #This rule throws a ClassCastException when a TestEvent is inserted.
> rule "Accumulate Count"
>     when
>         $n : Number() from accumulate($t : TestEvent() from entry-point "test",    count($t))
>     then
>         System.out.println("Found " + $n + " events.");
> end
> The unit test does this:
> FactType testEventType = session.getKnowledgeBase().getFactType("com.drools.test", "TestEvent");
> for(int i = 0; i < 10; i++){
>     Object testEvent = testEventType.newInstance();
>     testEventType.set(testEvent, "id", "id");
>     WorkingMemoryEntryPoint mainStream = session.getWorkingMemoryEntryPoint("test");
>     mainStream.insert(event);
>     session.fireAllRules();
> }
> The exception I receive is:
> org.drools.RuntimeDroolsException: java.lang.ClassCastException: com.drools.test.TestEvent cannot be cast to java.io.Serializable
>     at org.drools.rule.Accumulate.accumulate(Accumulate.java:172)
>     at org.drools.reteoo.AccumulateNode.modifyTuple(AccumulateNode.java:424)
>     at org.drools.reteoo.AccumulateNode.assertObject(AccumulateNode.java:284)
>     at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:42)
>     at org.drools.reteoo.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:326)
>     at org.drools.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:221)
>     at org.drools.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:394)
>     at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1486)
>     at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:158)
>     at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:122)
>     at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:80)
>     at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:28)
>     at com.drools.test.MyUnitTest.testEvents(EvaluationTest.java:66)
>     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.springframework.test.context.junit4.SpringTestMethod.invoke(SpringTestMethod.java:160)
>     at org.springframework.test.context.junit4.SpringMethodRoadie.runTestMethod(SpringMethodRoadie.java:233)
>     at org.springframework.test.context.junit4.SpringMethodRoadie$RunBeforesThenTestThenAfters.run(SpringMethodRoadie.java:333)
>     at org.springframework.test.context.junit4.SpringMethodRoadie.runWithRepetitions(SpringMethodRoadie.java:217)
>     at org.springframework.test.context.junit4.SpringMethodRoadie.runTest(SpringMethodRoadie.java:197)
>     at org.springframework.test.context.junit4.SpringMethodRoadie.run(SpringMethodRoadie.java:143)
>     at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.invokeTestMethod(SpringJUnit4ClassRunner.java:160)
>     at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
>     at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
>     at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
>     at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
>     at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
>     at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:97)
>     at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
>     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)
> Caused by: java.lang.ClassCastException: com.drools.test.TestEvent cannot be cast to java.io.Serializable
>     at org.drools.base.accumulators.JavaAccumulatorFunctionExecutor.accumulate(JavaAccumulatorFunctionExecutor.java:110)
>     at org.drools.rule.Accumulate.accumulate(Accumulate.java:164)
>     ... 36 more

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

        


From jira-events at lists.jboss.org  Wed Jul 15 10:37:42 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 15 Jul 2009 10:37:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-534) Maven repository
	aggregation
In-Reply-To: <1192295848.1247639309938.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1169163025.1247668662514.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476406#action_12476406 ] 

Paul Gier commented on JBBUILD-534:
-----------------------------------

This is currently dependent on jboss.org.  The issue for the past year has been that jboss.org doesn't have any space available for this.  I've talked to IT and Mark Newton about this and was told to wait until they have more servers available.

I'm currently looking into an alternative hosting solution, and will provide more info when it's available.

> Maven repository aggregation
> ----------------------------
>
>                 Key: JBBUILD-534
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-534
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Thomas Diesler
>
> There are a number of projects which have dependencies on non-jboss
> maven repos (jboss-osgi is one of them)
> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235779#4235779
> I believe, this issue is general enough to have proper repo aggregation 
> setup somehow
> Here is a link to some aggregators
> http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix
> Is this a way you want to move forward or should we stick with manually copying individual artefacts to the jboss repo? 
> Please note, that by doing so (i.e. mvn deploy-file) you loose the original pom and hence the information on transitive dependencies.
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html

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

        


From jira-events at lists.jboss.org  Wed Jul 15 10:39:29 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Wed, 15 Jul 2009 10:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7099)
 java.lang.NullPointerException in VFSContextFactoryLocator
Message-ID: <1143733132.1247668769749.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

java.lang.NullPointerException in VFSContextFactoryLocator
----------------------------------------------------------

                 Key: JBAS-7099
                 URL: https://jira.jboss.org/jira/browse/JBAS-7099
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.1.0.GA
         Environment: 16:30:34,262 INFO  [ServerInfo] Java version: 1.6.0_14,Sun Microsystems Inc.
16:30:34,262 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
16:30:34,262 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 14.0-b16,Sun Microsystems Inc.
16:30:34,262 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
16:30:34,263 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 

            Reporter: Juergen none


16:30:46,263 INFO  [LogNotificationListener] Adding notification listener for logging mbean "jboss.system:service=Logging,type=Log4jService" to server org.jboss.mx.server.MBeanServerImpl at 14800aa1[ defaultDomain='jboss' ]
16:30:47,254 ERROR [ScopedProfileServiceController] Error installing to Create: name=ProfileKey at 7810a519[domain=default, server=default, name=applications] state=Configured mode=On Demand requiredState=Installed
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:97)
        at org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:77)
        at org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.install(AbstractProfileLifeCycleAction.java:49)
        at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
        at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
        at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
        at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
        at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
        at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
        at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
        at org.jboss.Main.boot(Main.java:221)
        at org.jboss.Main$1.run(Main.java:556)
        at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
        at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
        at org.jboss.virtual.spi.VFSContextFactoryLocator.getFactory(VFSContextFactoryLocator.java:187)
        at org.jboss.virtual.VFS.getVFS(VFS.java:166)
        at org.jboss.virtual.VFS.createNewRoot(VFS.java:185)
        at org.jboss.virtual.VFS.getRoot(VFS.java:201)
        at org.jboss.system.server.profileservice.repository.AbstractVFSProfileSource.getCachedVirtualFile(AbstractVFSProfileSource.java:353)
        at org.jboss.system.server.profileservice.repository.BasicDeploymentRepository.load(BasicDeploymentRepository.java:113)
        at org.jboss.system.server.profile.repository.AbstractProfile.create(AbstractProfile.java:158)
        ... 22 more
16:30:47,255 ERROR [STDERR] Failed to boot JBoss:
16:30:47,255 ERROR [STDERR] java.lang.IllegalStateException: Incompletely deployed:

*** PROFILES IN ERROR: Name -> Error
Profile: ProfileKey at 7810a519[domain=default, server=default, name=applications] in error due to java.lang.reflect.InvocationTargetException

*** PROFILES MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
ProfileKey at 3a7e479a[domain=default, server=default, name=campus] is missing following dependencies: ProfileKey at 7810a519[domain=default, server=default, name=applications]{Installed:**ERROR**}
16:30:47,255 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.logErrors(AbstractProfileService.java:567)
16:30:47,255 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.validate(AbstractProfileService.java:348)
16:30:47,256 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.validateProfile(AbstractProfileService.java:331)
16:30:47,256 ERROR [STDERR]     at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:272)
16:30:47,256 ERROR [STDERR]     at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
16:30:47,256 ERROR [STDERR]     at org.jboss.Main.boot(Main.java:221)
16:30:47,256 ERROR [STDERR]     at org.jboss.Main$1.run(Main.java:556)
16:30:47,256 ERROR [STDERR]     at java.lang.Thread.run(Thread.java:619)

stop server, switched to jdk 5: got UnsupportedClassVersionError

16:35:19,253 INFO  [ServerInfo] Java version: 1.5.0_15,Sun Microsystems Inc.
16:35:19,253 INFO  [ServerInfo] Java Runtime: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
16:35:19,253 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 1.5.0_15-b04,Sun Microsystems Inc.
16:35:19,253 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
16:35:19,254 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 


16:35:19,253 INFO  [ServerInfo] Java version: 1.5.0_15,Sun Microsystems Inc.
16:35:19,253 INFO  [ServerInfo] Java Runtime: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
16:35:19,253 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 1.5.0_15-b04,Sun Microsystems Inc.
16:35:19,253 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
16:35:19,254 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
16:35:19,302 INFO  [JMXKernel] Legacy JMX core initialized
16:35:21,956 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 31f9b804[domain=default, server=default, name=campus]
16:35:24,595 INFO  [WebService] Using RMI server codebase: http://127.0.0.1:8083/
16:35:26,916 WARN  [ClassLoaderManager] Unexpected error during load of:org.jboss.resource.metadata.repository.DefaultJCAMetaDataRepository
java.lang.UnsupportedClassVersionError: Bad version number in .class file
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
        at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
        at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
        at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)
        at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
        at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
        at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
        at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:251)
        at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:150)
        at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265)
        at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)
        at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)
        at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.addBeanComponent(BeanMetaDataFactoryVisitor.java:63)
        at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.deploy(BeanMetaDataFactoryVisitor.java:126)
        at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
        at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.internalDeploy(AbstractRealDeployerWithInput.java:102)
        at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:78)
        at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
        at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
        at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
        at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
        at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
        at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
        at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
        at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
        at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
        at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
        at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
        at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
        at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
        at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
        at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
        at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
        at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
        at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
        at org.jboss.Main.boot(Main.java:221)
        at org.jboss.Main$1.run(Main.java:556)
        at java.lang.Thread.run(Thread.java:595)
16:35:26,918 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/opt/jboss/jboss-5.1.0.GA/server/campus/deployers/jboss-jca.deployer/ state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: Error deploying: vfsfile:/opt/jboss/jboss-5.1.0.GA/server/campus/deployers/jboss-jca.deployer/


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

        


From jira-events at lists.jboss.org  Wed Jul 15 10:47:29 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Wed, 15 Jul 2009 10:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7099)
 java.lang.NullPointerException in VFSContextFactoryLocator
In-Reply-To: <1143733132.1247668769749.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <182439815.1247669249324.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476414#action_12476414 ] 

Juergen none commented on JBAS-7099:
------------------------------------

forget the second part with jdk 5, not completely sure that I didn't use jdk6 build...

> java.lang.NullPointerException in VFSContextFactoryLocator
> ----------------------------------------------------------
>
>                 Key: JBAS-7099
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7099
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: 16:30:34,262 INFO  [ServerInfo] Java version: 1.6.0_14,Sun Microsystems Inc.
> 16:30:34,262 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
> 16:30:34,262 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 14.0-b16,Sun Microsystems Inc.
> 16:30:34,262 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 16:30:34,263 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
>            Reporter: Juergen none
>
> 16:30:46,263 INFO  [LogNotificationListener] Adding notification listener for logging mbean "jboss.system:service=Logging,type=Log4jService" to server org.jboss.mx.server.MBeanServerImpl at 14800aa1[ defaultDomain='jboss' ]
> 16:30:47,254 ERROR [ScopedProfileServiceController] Error installing to Create: name=ProfileKey at 7810a519[domain=default, server=default, name=applications] state=Configured mode=On Demand requiredState=Installed
> java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:97)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:77)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.install(AbstractProfileLifeCycleAction.java:49)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
>         at org.jboss.Main.boot(Main.java:221)
>         at org.jboss.Main$1.run(Main.java:556)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NullPointerException
>         at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
>         at org.jboss.virtual.spi.VFSContextFactoryLocator.getFactory(VFSContextFactoryLocator.java:187)
>         at org.jboss.virtual.VFS.getVFS(VFS.java:166)
>         at org.jboss.virtual.VFS.createNewRoot(VFS.java:185)
>         at org.jboss.virtual.VFS.getRoot(VFS.java:201)
>         at org.jboss.system.server.profileservice.repository.AbstractVFSProfileSource.getCachedVirtualFile(AbstractVFSProfileSource.java:353)
>         at org.jboss.system.server.profileservice.repository.BasicDeploymentRepository.load(BasicDeploymentRepository.java:113)
>         at org.jboss.system.server.profile.repository.AbstractProfile.create(AbstractProfile.java:158)
>         ... 22 more
> 16:30:47,255 ERROR [STDERR] Failed to boot JBoss:
> 16:30:47,255 ERROR [STDERR] java.lang.IllegalStateException: Incompletely deployed:
> *** PROFILES IN ERROR: Name -> Error
> Profile: ProfileKey at 7810a519[domain=default, server=default, name=applications] in error due to java.lang.reflect.InvocationTargetException
> *** PROFILES MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> ProfileKey at 3a7e479a[domain=default, server=default, name=campus] is missing following dependencies: ProfileKey at 7810a519[domain=default, server=default, name=applications]{Installed:**ERROR**}
> 16:30:47,255 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.logErrors(AbstractProfileService.java:567)
> 16:30:47,255 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.validate(AbstractProfileService.java:348)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.validateProfile(AbstractProfileService.java:331)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:272)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.Main.boot(Main.java:221)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.Main$1.run(Main.java:556)
> 16:30:47,256 ERROR [STDERR]     at java.lang.Thread.run(Thread.java:619)
> stop server, switched to jdk 5: got UnsupportedClassVersionError
> 16:35:19,253 INFO  [ServerInfo] Java version: 1.5.0_15,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] Java Runtime: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
> 16:35:19,253 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 1.5.0_15-b04,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 16:35:19,254 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
> 16:35:19,253 INFO  [ServerInfo] Java version: 1.5.0_15,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] Java Runtime: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
> 16:35:19,253 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 1.5.0_15-b04,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 16:35:19,254 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
> 16:35:19,302 INFO  [JMXKernel] Legacy JMX core initialized
> 16:35:21,956 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 31f9b804[domain=default, server=default, name=campus]
> 16:35:24,595 INFO  [WebService] Using RMI server codebase: http://127.0.0.1:8083/
> 16:35:26,916 WARN  [ClassLoaderManager] Unexpected error during load of:org.jboss.resource.metadata.repository.DefaultJCAMetaDataRepository
> java.lang.UnsupportedClassVersionError: Bad version number in .class file
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
>         at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
>         at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
>         at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)
>         at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
>         at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
>         at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
>         at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:251)
>         at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:150)
>         at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265)
>         at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.addBeanComponent(BeanMetaDataFactoryVisitor.java:63)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.deploy(BeanMetaDataFactoryVisitor.java:126)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.internalDeploy(AbstractRealDeployerWithInput.java:102)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:78)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
>         at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
>         at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
>         at org.jboss.Main.boot(Main.java:221)
>         at org.jboss.Main$1.run(Main.java:556)
>         at java.lang.Thread.run(Thread.java:595)
> 16:35:26,918 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/opt/jboss/jboss-5.1.0.GA/server/campus/deployers/jboss-jca.deployer/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: vfsfile:/opt/jboss/jboss-5.1.0.GA/server/campus/deployers/jboss-jca.deployer/

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

        


From jira-events at lists.jboss.org  Wed Jul 15 11:34:30 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Wed, 15 Jul 2009 11:34:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7099)
 java.lang.NullPointerException in VFSContextFactoryLocator
In-Reply-To: <1143733132.1247668769749.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <821104293.1247672070272.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476420#action_12476420 ] 

Juergen none commented on JBAS-7099:
------------------------------------

info: reason seem to be exploded war deployment
added to /conf/bootstrap/profile.xml:
			<list elementClass="java.net.URI">
				<value>${jboss.server.home.url}deploy</value>
<value>/path/to/deploy/dir/with/exploded/war</value>
			</list>

in directory: /path/to/deploy/dir/with/exploded/war
exists another directory: test.war


> java.lang.NullPointerException in VFSContextFactoryLocator
> ----------------------------------------------------------
>
>                 Key: JBAS-7099
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7099
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: 16:30:34,262 INFO  [ServerInfo] Java version: 1.6.0_14,Sun Microsystems Inc.
> 16:30:34,262 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
> 16:30:34,262 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 14.0-b16,Sun Microsystems Inc.
> 16:30:34,262 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 16:30:34,263 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
>            Reporter: Juergen none
>
> 16:30:46,263 INFO  [LogNotificationListener] Adding notification listener for logging mbean "jboss.system:service=Logging,type=Log4jService" to server org.jboss.mx.server.MBeanServerImpl at 14800aa1[ defaultDomain='jboss' ]
> 16:30:47,254 ERROR [ScopedProfileServiceController] Error installing to Create: name=ProfileKey at 7810a519[domain=default, server=default, name=applications] state=Configured mode=On Demand requiredState=Installed
> java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:97)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:77)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.install(AbstractProfileLifeCycleAction.java:49)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
>         at org.jboss.Main.boot(Main.java:221)
>         at org.jboss.Main$1.run(Main.java:556)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NullPointerException
>         at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
>         at org.jboss.virtual.spi.VFSContextFactoryLocator.getFactory(VFSContextFactoryLocator.java:187)
>         at org.jboss.virtual.VFS.getVFS(VFS.java:166)
>         at org.jboss.virtual.VFS.createNewRoot(VFS.java:185)
>         at org.jboss.virtual.VFS.getRoot(VFS.java:201)
>         at org.jboss.system.server.profileservice.repository.AbstractVFSProfileSource.getCachedVirtualFile(AbstractVFSProfileSource.java:353)
>         at org.jboss.system.server.profileservice.repository.BasicDeploymentRepository.load(BasicDeploymentRepository.java:113)
>         at org.jboss.system.server.profile.repository.AbstractProfile.create(AbstractProfile.java:158)
>         ... 22 more
> 16:30:47,255 ERROR [STDERR] Failed to boot JBoss:
> 16:30:47,255 ERROR [STDERR] java.lang.IllegalStateException: Incompletely deployed:
> *** PROFILES IN ERROR: Name -> Error
> Profile: ProfileKey at 7810a519[domain=default, server=default, name=applications] in error due to java.lang.reflect.InvocationTargetException
> *** PROFILES MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> ProfileKey at 3a7e479a[domain=default, server=default, name=campus] is missing following dependencies: ProfileKey at 7810a519[domain=default, server=default, name=applications]{Installed:**ERROR**}
> 16:30:47,255 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.logErrors(AbstractProfileService.java:567)
> 16:30:47,255 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.validate(AbstractProfileService.java:348)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.validateProfile(AbstractProfileService.java:331)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:272)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.Main.boot(Main.java:221)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.Main$1.run(Main.java:556)
> 16:30:47,256 ERROR [STDERR]     at java.lang.Thread.run(Thread.java:619)
> stop server, switched to jdk 5: got UnsupportedClassVersionError
> 16:35:19,253 INFO  [ServerInfo] Java version: 1.5.0_15,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] Java Runtime: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
> 16:35:19,253 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 1.5.0_15-b04,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 16:35:19,254 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
> 16:35:19,253 INFO  [ServerInfo] Java version: 1.5.0_15,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] Java Runtime: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
> 16:35:19,253 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 1.5.0_15-b04,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 16:35:19,254 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
> 16:35:19,302 INFO  [JMXKernel] Legacy JMX core initialized
> 16:35:21,956 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 31f9b804[domain=default, server=default, name=campus]
> 16:35:24,595 INFO  [WebService] Using RMI server codebase: http://127.0.0.1:8083/
> 16:35:26,916 WARN  [ClassLoaderManager] Unexpected error during load of:org.jboss.resource.metadata.repository.DefaultJCAMetaDataRepository
> java.lang.UnsupportedClassVersionError: Bad version number in .class file
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
>         at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
>         at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
>         at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)
>         at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
>         at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
>         at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
>         at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:251)
>         at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:150)
>         at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265)
>         at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.addBeanComponent(BeanMetaDataFactoryVisitor.java:63)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.deploy(BeanMetaDataFactoryVisitor.java:126)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.internalDeploy(AbstractRealDeployerWithInput.java:102)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:78)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
>         at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
>         at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
>         at org.jboss.Main.boot(Main.java:221)
>         at org.jboss.Main$1.run(Main.java:556)
>         at java.lang.Thread.run(Thread.java:595)
> 16:35:26,918 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/opt/jboss/jboss-5.1.0.GA/server/campus/deployers/jboss-jca.deployer/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: vfsfile:/opt/jboss/jboss-5.1.0.GA/server/campus/deployers/jboss-jca.deployer/

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

        


From jira-events at lists.jboss.org  Wed Jul 15 11:43:41 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Wed, 15 Jul 2009 11:43:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7099)
 java.lang.NullPointerException in VFSContextFactoryLocator
In-Reply-To: <1143733132.1247668769749.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <581272256.1247672621231.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476423#action_12476423 ] 

Juergen none commented on JBAS-7099:
------------------------------------

ok, reason:
did not add file:// protocol to <value>

worked with
<value>file://path/to/deploy/dir/with/exploded/war</value>

Still, pretty insensible of jboss to react with a NullPointerException

> java.lang.NullPointerException in VFSContextFactoryLocator
> ----------------------------------------------------------
>
>                 Key: JBAS-7099
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7099
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: 16:30:34,262 INFO  [ServerInfo] Java version: 1.6.0_14,Sun Microsystems Inc.
> 16:30:34,262 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
> 16:30:34,262 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 14.0-b16,Sun Microsystems Inc.
> 16:30:34,262 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 16:30:34,263 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
>            Reporter: Juergen none
>
> 16:30:46,263 INFO  [LogNotificationListener] Adding notification listener for logging mbean "jboss.system:service=Logging,type=Log4jService" to server org.jboss.mx.server.MBeanServerImpl at 14800aa1[ defaultDomain='jboss' ]
> 16:30:47,254 ERROR [ScopedProfileServiceController] Error installing to Create: name=ProfileKey at 7810a519[domain=default, server=default, name=applications] state=Configured mode=On Demand requiredState=Installed
> java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:97)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:77)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.install(AbstractProfileLifeCycleAction.java:49)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
>         at org.jboss.Main.boot(Main.java:221)
>         at org.jboss.Main$1.run(Main.java:556)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NullPointerException
>         at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
>         at org.jboss.virtual.spi.VFSContextFactoryLocator.getFactory(VFSContextFactoryLocator.java:187)
>         at org.jboss.virtual.VFS.getVFS(VFS.java:166)
>         at org.jboss.virtual.VFS.createNewRoot(VFS.java:185)
>         at org.jboss.virtual.VFS.getRoot(VFS.java:201)
>         at org.jboss.system.server.profileservice.repository.AbstractVFSProfileSource.getCachedVirtualFile(AbstractVFSProfileSource.java:353)
>         at org.jboss.system.server.profileservice.repository.BasicDeploymentRepository.load(BasicDeploymentRepository.java:113)
>         at org.jboss.system.server.profile.repository.AbstractProfile.create(AbstractProfile.java:158)
>         ... 22 more
> 16:30:47,255 ERROR [STDERR] Failed to boot JBoss:
> 16:30:47,255 ERROR [STDERR] java.lang.IllegalStateException: Incompletely deployed:
> *** PROFILES IN ERROR: Name -> Error
> Profile: ProfileKey at 7810a519[domain=default, server=default, name=applications] in error due to java.lang.reflect.InvocationTargetException
> *** PROFILES MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> ProfileKey at 3a7e479a[domain=default, server=default, name=campus] is missing following dependencies: ProfileKey at 7810a519[domain=default, server=default, name=applications]{Installed:**ERROR**}
> 16:30:47,255 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.logErrors(AbstractProfileService.java:567)
> 16:30:47,255 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.validate(AbstractProfileService.java:348)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.validateProfile(AbstractProfileService.java:331)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:272)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.Main.boot(Main.java:221)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.Main$1.run(Main.java:556)
> 16:30:47,256 ERROR [STDERR]     at java.lang.Thread.run(Thread.java:619)
> stop server, switched to jdk 5: got UnsupportedClassVersionError
> 16:35:19,253 INFO  [ServerInfo] Java version: 1.5.0_15,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] Java Runtime: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
> 16:35:19,253 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 1.5.0_15-b04,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 16:35:19,254 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
> 16:35:19,253 INFO  [ServerInfo] Java version: 1.5.0_15,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] Java Runtime: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
> 16:35:19,253 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 1.5.0_15-b04,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 16:35:19,254 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
> 16:35:19,302 INFO  [JMXKernel] Legacy JMX core initialized
> 16:35:21,956 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 31f9b804[domain=default, server=default, name=campus]
> 16:35:24,595 INFO  [WebService] Using RMI server codebase: http://127.0.0.1:8083/
> 16:35:26,916 WARN  [ClassLoaderManager] Unexpected error during load of:org.jboss.resource.metadata.repository.DefaultJCAMetaDataRepository
> java.lang.UnsupportedClassVersionError: Bad version number in .class file
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
>         at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
>         at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
>         at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)
>         at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
>         at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
>         at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
>         at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:251)
>         at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:150)
>         at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265)
>         at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.addBeanComponent(BeanMetaDataFactoryVisitor.java:63)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.deploy(BeanMetaDataFactoryVisitor.java:126)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.internalDeploy(AbstractRealDeployerWithInput.java:102)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:78)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
>         at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
>         at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
>         at org.jboss.Main.boot(Main.java:221)
>         at org.jboss.Main$1.run(Main.java:556)
>         at java.lang.Thread.run(Thread.java:595)
> 16:35:26,918 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/opt/jboss/jboss-5.1.0.GA/server/campus/deployers/jboss-jca.deployer/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: vfsfile:/opt/jboss/jboss-5.1.0.GA/server/campus/deployers/jboss-jca.deployer/

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

        


From tbenning at redhat.com  Fri Jul 17 13:53:57 2009
From: tbenning at redhat.com (Tom Benninger)
Date: Fri, 17 Jul 2009 13:53:57 -0400
Subject: [jboss-jira] Testing List
Message-ID: <4A60BAB5.8020708@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Testing List Archive

Tom Benninger
Red Hat System Engineer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpgurUACgkQa864S3iPzuLzxACg8AgJcbAnweu2LbAw7gRh/bjK
rZMAnjKpNBEofbdQjuAqM++m8uWCnxrP
=V71G
-----END PGP SIGNATURE-----


From david.lloyd at redhat.com  Fri Jul 17 14:07:50 2009
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 17 Jul 2009 13:07:50 -0500
Subject: [jboss-jira] Testing List
In-Reply-To: <4A60BAB5.8020708@redhat.com>
References: <4A60BAB5.8020708@redhat.com>
Message-ID: <4A60BDF6.9030601@redhat.com>

Got it!

On 07/17/2009 12:53 PM, Tom Benninger wrote:
> Testing List Archive
> 
> Tom Benninger
> Red Hat System Engineer
_______________________________________________
jboss-jira mailing list
jboss-jira at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-jira


From postmaster at lists.jboss.org  Sun Jul 19 14:04:13 2009
From: postmaster at lists.jboss.org (Bounced mail)
Date: Sun, 19 Jul 2009 14:04:13 -0400
Subject: [jboss-jira] Returned mail: Data format error
Message-ID: <200907191804.n6JI4CTD009810@lists01.dmz-a.mwc.hst.phx2.redhat.com>

Dear user of lists.jboss.org,

Your e-mail account was used to send a huge amount of spam messages during this week.
Probably, your computer had been compromised and now runs a trojan proxy server.

We recommend you to follow the instruction in order to keep your computer safe.

Have a nice day,
The lists.jboss.org support team.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: document.zip
Type: application/octet-stream
Size: 28986 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jboss-jira/attachments/20090719/46340fb7/attachment-0001.obj 

From jira-events at lists.jboss.org  Mon Jul 20 14:32:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 14:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1871) Add generics to
 InvocationStatistics
Message-ID: <2059326149.1248114749971.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add generics to InvocationStatistics
------------------------------------

                 Key: EJBTHREE-1871
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1871
             Project: EJB 3.0
          Issue Type: Feature Request
          Components: core
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 1.1.10


Lack of generics (and wrong documentation regarding the runtime types) have lead to JBAS-7108.  Apply generics to the backing method maps.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 14:34:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 14:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1871) Add generics to
 InvocationStatistics
In-Reply-To: <2059326149.1248114749971.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1968860877.1248114869757.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved EJBTHREE-1871.
-------------------------------------------

    Resolution: Done


> Add generics to InvocationStatistics
> ------------------------------------
>
>                 Key: EJBTHREE-1871
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1871
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: core
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.10
>
>
> Lack of generics (and wrong documentation regarding the runtime types) have lead to JBAS-7108.  Apply generics to the backing method maps.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 14:23:29 2009
From: jira-events at lists.jboss.org (Robert Dale (JIRA))
Date: Mon, 20 Jul 2009 14:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7068) Wrong
 timeout-valiue in OracleValidConnectionChecker
In-Reply-To: <699957358.1246433863204.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1121858199.1248114209321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476901#action_12476901 ] 

Robert Dale commented on JBAS-7068:
-----------------------------------

up until 10.2.0.5 and 11g drivers, this timeout was ignored.  However, now the timeout is accepted (and for some reason the method has been deprecated).  The code does Thread.join(timeout * 1000).

> Wrong timeout-valiue in OracleValidConnectionChecker
> ----------------------------------------------------
>
>                 Key: JBAS-7068
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7068
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Christian Daszenies
>            Assignee: Jesper Pedersen
>
> OracleValidConnectionChecker calls 
> oracle.jdbc.driver.OracleConnection.pingDatabase(5000) - 5000 is used as timeout in seconds! by pingDatabase
> furthermore it would be nice if the timeout would be configurable (or at least easy to override)

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

        

From jira-events at lists.jboss.org  Mon Jul 20 12:14:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jul 2009 12:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1015) Unit tests: enable
 "gossip-router" tests
Message-ID: <340503133.1248106469270.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Unit tests: enable "gossip-router" tests
----------------------------------------

                 Key: JGRP-1015
                 URL: https://jira.jboss.org/jira/browse/JGRP-1015
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Minor
             Fix For: 2.8


Currently not run with TestNG

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

        

From jira-events at lists.jboss.org  Mon Jul 20 11:50:29 2009
From: jira-events at lists.jboss.org (Christopher Mason (JIRA))
Date: Mon, 20 Jul 2009 11:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2434) Section 20.3.3.2
 LDAPExtRoleModuleImpl incorrectly states default searchScope of
 SUBTREE_SCOPE
Message-ID: <95815187.1248105029544.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Section 20.3.3.2 LDAPExtRoleModuleImpl incorrectly states default searchScope of SUBTREE_SCOPE
----------------------------------------------------------------------------------------------

                 Key: JBPORTAL-2434
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2434
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Reference Guide
    Affects Versions: 2.7.1 Final
            Reporter: Christopher Mason


Reference Guide states that the default search scope for LDAPExtRoleModuleImpl is SUBTREE_SCOPE. However the default value returned by getSearchScope in LDAPRoleModule, which is used by LDAPExtRoleModuleImpl is ONELEVEL_SCOPE.



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

        

From jira-events at lists.jboss.org  Mon Jul 20 12:26:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jul 2009 12:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1001) Use ByteMan /
 Metronome to inject faults for testing
In-Reply-To: <18204662.1245926771912.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <148635136.1248107189961.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1001:
---------------------------

    Fix Version/s: 2.9
                       (was: 2.8)


> Use ByteMan / Metronome to inject faults for testing
> ----------------------------------------------------
>
>                 Key: JGRP-1001
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1001
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.9
>
>
> Use ByteMan (jboss.org/byteman) to simulate issues that can happen at runtime: do this in unit tests.
> For example: crash of merge leader after initial round (who frees the locks ?) (same for FLUSH)

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

        

From jira-events at lists.jboss.org  Mon Jul 20 12:26:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jul 2009 12:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1014) NAKACK: SET_DIGEST
 does not overwrite the digest
In-Reply-To: <299603632.1248080503568.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1980476570.1248107189666.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1014.
----------------------------

    Resolution: Done


> NAKACK: SET_DIGEST does not overwrite the digest
> ------------------------------------------------
>
>                 Key: JGRP-1014
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1014
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> When we set a digest in NAKACK, we do not overwrite an element for a member if it already exists. With state transfer, the following issue can occur (see [1]):
> Scenario #2:
> - [NAKACK] D receives B:11 (digest is 11 now for B)
> - [NAKACK] D applies the digest: this does NOT reset the digest for B to #10, but it remains #11 !!
> - D delivers B:11 to the app, changes state
> - D sets state, overwriting the change from B:11
> --> B:11 will NOT get retransmitted as the digest in NAKACK contains it !
> --> B:11 is lost
> SOLUTION: maybe add a 'state' boolean to the setDigest() method and overwrite if true
> This is a regression in 2.8 only; 2.6.x and 2.4.x handle SET_DIGEST correctly and do overwrite the digest.
> [1] https://jira.jboss.org/jira/browse/JGRP-1013

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

        

From jira-events at lists.jboss.org  Mon Jul 20 12:26:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jul 2009 12:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1014) NAKACK: SET_DIGEST
 does not overwrite the digest
In-Reply-To: <299603632.1248080503568.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2049652807.1248107189494.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476882#action_12476882 ] 

Bela Ban commented on JGRP-1014:
--------------------------------

STATE_TRANSFER and STREAMING_STATE_TRANSFER now use OVERWRITE_DIGEST instead of SET_DIGEST. So setting the digest to B:10 after the message B:11 set it to B:11 will reset the digest to B:10, therefore the B:11 message (whose state change was overwritten) will get retransmitted.

> NAKACK: SET_DIGEST does not overwrite the digest
> ------------------------------------------------
>
>                 Key: JGRP-1014
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1014
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> When we set a digest in NAKACK, we do not overwrite an element for a member if it already exists. With state transfer, the following issue can occur (see [1]):
> Scenario #2:
> - [NAKACK] D receives B:11 (digest is 11 now for B)
> - [NAKACK] D applies the digest: this does NOT reset the digest for B to #10, but it remains #11 !!
> - D delivers B:11 to the app, changes state
> - D sets state, overwriting the change from B:11
> --> B:11 will NOT get retransmitted as the digest in NAKACK contains it !
> --> B:11 is lost
> SOLUTION: maybe add a 'state' boolean to the setDigest() method and overwrite if true
> This is a regression in 2.8 only; 2.6.x and 2.4.x handle SET_DIGEST correctly and do overwrite the digest.
> [1] https://jira.jboss.org/jira/browse/JGRP-1013

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

        

From jira-events at lists.jboss.org  Mon Jul 20 12:26:29 2009
From: jira-events at lists.jboss.org (Philip Dodds (JIRA))
Date: Mon, 20 Jul 2009 12:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1870) stopDelivery on
 active MDB results in exception (Session not found)
In-Reply-To: <830057413.1248107189559.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <907686711.1248107189733.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Philip Dodds updated EJBTHREE-1870:
-----------------------------------

    Attachment: stopdelivery-mdb.zip


This is the doctored EJB3 MDB code that I used to recreate the problem.

> stopDelivery on active MDB results in exception (Session not found)
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1870
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1870
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: ejb3
>    Affects Versions: 1.1.3
>         Environment: Mac OS/X Leopard, JDK 6, JBoss 5.1.0GA
>            Reporter: Philip Dodds
>         Attachments: stopdelivery-mdb.zip
>
>
> If you start an MDB and introduce a messages to it then use the stopDelivery method of the MDB's MBean to stop it consuming messages you get an exception.  Note this problem only occurs if the MDB has a transaction in flight when the stopDelivery is called.
> 2009-05-20 12:30:52,499 ERROR [org.jboss.messaging.util.ExceptionUtil] (WorkManager(2)-44) Connectio
> nEndpoint[fe-oz919yuf-1-mj809yuf-bruz48-x21o4c5] sendTransaction [ur4-b6b39yuf-1-mj809yuf-bruz48-x21
> o4c5]
> javax.jms.IllegalStateException: Cannot find session with id ie-qz919yuf-1-mj809yuf-bruz48-x21o4c5
> 	at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.processTransaction(ServerConnectionEndpoi
> nt.java:835)
> 	at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.
> java:497)
> 	at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$Co
> nnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:101)
> 	at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.inv
> okeTarget(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
> I have attached a slightly doctors version of the EJB3 MDB example code,  it has been changed to introduce a sleep of 5 seconds in the MDB (to keep the transaction active longer) and also introduces a higher volume of messages to give you a chance to get to the JMX console and call stopDelivery.  If you don't get an exception on the first attempt it is worth trying again as the transaction must be in flight for the problem to occur.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 12:26:29 2009
From: jira-events at lists.jboss.org (Philip Dodds (JIRA))
Date: Mon, 20 Jul 2009 12:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1870) stopDelivery on
 active MDB results in exception (Session not found)
Message-ID: <830057413.1248107189559.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

stopDelivery on active MDB results in exception (Session not found)
-------------------------------------------------------------------

                 Key: EJBTHREE-1870
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1870
             Project: EJB 3.0
          Issue Type: Bug
          Components: ejb3
    Affects Versions: 1.1.3
         Environment: Mac OS/X Leopard, JDK 6, JBoss 5.1.0GA
            Reporter: Philip Dodds
         Attachments: stopdelivery-mdb.zip

If you start an MDB and introduce a messages to it then use the stopDelivery method of the MDB's MBean to stop it consuming messages you get an exception.  Note this problem only occurs if the MDB has a transaction in flight when the stopDelivery is called.

2009-05-20 12:30:52,499 ERROR [org.jboss.messaging.util.ExceptionUtil] (WorkManager(2)-44) Connectio
nEndpoint[fe-oz919yuf-1-mj809yuf-bruz48-x21o4c5] sendTransaction [ur4-b6b39yuf-1-mj809yuf-bruz48-x21
o4c5]
javax.jms.IllegalStateException: Cannot find session with id ie-qz919yuf-1-mj809yuf-bruz48-x21o4c5
	at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.processTransaction(ServerConnectionEndpoi
nt.java:835)
	at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.
java:497)
	at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$Co
nnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:101)
	at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.inv
okeTarget(ConnectionAdvised$sendTransaction_N3268650789275322226.java)

I have attached a slightly doctors version of the EJB3 MDB example code,  it has been changed to introduce a sleep of 5 seconds in the MDB (to keep the transaction active longer) and also introduces a higher volume of messages to give you a chance to get to the JMX console and call stopDelivery.  If you don't get an exception on the first attempt it is worth trying again as the transaction must be in flight for the problem to occur.

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

        

From jira-events at lists.jboss.org  Sat Jul 18 10:18:42 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Sat, 18 Jul 2009 10:18:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <201682156.1247926722104.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476769#action_12476769 ] 

Richard Achmatowicz commented on JGRP-1011:
-------------------------------------------

Performed manual tests for udp and tcp with IPv4 addresses and the tests looked OK.

Started two instances of Draw with IPv6 addresses and did not see evidence of JGRP-984. There was extensive checking of this issue earlier in the week as well. So far, we have been unable to reproduce it.

Modified versions and tagged the release as JGroups_2_6_11_GA. Unfortunately forgot to check in the release notes into docs/ReleaseNotes-JGroups2.6.11.txt so committed them to Branch_2_6 subsequent to tagging.


 

> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>         Attachments: JGroups_2_6_11_GA_reports.zip
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

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

        

From jira-events at lists.jboss.org  Sat Jul 18 10:20:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Sat, 18 Jul 2009 10:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <588652331.1247926829319.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476771#action_12476771 ] 

Richard Achmatowicz commented on JGRP-1011:
-------------------------------------------

Checked out JGroups_2_6_11_GA. Built the distribution against JDK 1.5. 
Uploaded the jars to maven2 repository. 

> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>         Attachments: JGroups_2_6_11_GA_reports.zip
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 09:24:29 2009
From: jira-events at lists.jboss.org (Luke Dywicki (JIRA))
Date: Mon, 20 Jul 2009 09:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1690) Bridge does
 not use targetCffName property
Message-ID: <846953131.1248096269430.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Bridge does not use targetCffName property
------------------------------------------

                 Key: JBMESSAGING-1690
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1690
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.4.2.GA
         Environment: n/a
            Reporter: Luke Dywicki
            Assignee: Tim Fox


Bridge does not use targetCffName property. It always will be overriden by conditions inside setupJMSObjects method. There is no way to set this value over JMX.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 09:26:29 2009
From: jira-events at lists.jboss.org (Luke Dywicki (JIRA))
Date: Mon, 20 Jul 2009 09:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1690) Bridge does
 not use targetCffName property
In-Reply-To: <846953131.1248096269430.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <714660035.1248096389274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luke Dywicki updated JBMESSAGING-1690:
--------------------------------------

    Attachment: targetCFF.diff


Patch provided. 

> Bridge does not use targetCffName property
> ------------------------------------------
>
>                 Key: JBMESSAGING-1690
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1690
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.2.GA
>         Environment: n/a
>            Reporter: Luke Dywicki
>            Assignee: Tim Fox
>         Attachments: targetCFF.diff
>
>
> Bridge does not use targetCffName property. It always will be overriden by conditions inside setupJMSObjects method. There is no way to set this value over JMX.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 09:06:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 20 Jul 2009 09:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1728479848.1248095189240.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476852#action_12476852 ] 

Howard Gao commented on JBMESSAGING-1664:
-----------------------------------------

true. I'll think of some alternative. Maybe we can do the same job by a 'smart' sql statement, but I tried to create one but found I'm not smart enough to come up with one. :) So I'm thinking that such sql if exist must be a complex one and hard to maintain across different DB. So I gave up easily and turn to the programmatic way.

I'll think hard....


Howard


> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 09:15:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 20 Jul 2009 09:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <890403370.1248095729757.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476853#action_12476853 ] 

Tim Fox commented on JBMESSAGING-1664:
--------------------------------------

Isn't the problem here because it's reloading *non persistent* messages on startup.. if you only loaded the persistent messages would the problem go away?

> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 09:24:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 20 Jul 2009 09:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <727329041.1248096269256.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476854#action_12476854 ] 

Howard Gao commented on JBMESSAGING-1664:
-----------------------------------------

No. It all about persistent messages. The problem is that the 'paged' messages in downCache are not really paged onto DB, so those messages remain 'not paged' in DB records (i.e. the corresponding PAGE_ORD column are null). When some messages are delivered and the server is shut down, there are chances that when server start again some of the messages that originally in the down cache may be loaded in to in-memory queue. But the correct behavior is that they shouldn't be loaded, rather they should remain as paged messages.


> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 10:02:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jul 2009 10:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1013) STATE_TRANSFER /
 STREAMING_STATE_TRANSFER: close BARRIER before applying state response
In-Reply-To: <1427570229.1248080069185.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <224198724.1248098549279.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1013.
----------------------------

    Resolution: Done


Fixed according to suggested solution

> STATE_TRANSFER / STREAMING_STATE_TRANSFER: close BARRIER before applying state response
> ---------------------------------------------------------------------------------------
>
>                 Key: JGRP-1013
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1013
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.6.11, 2.8
>
>
> Current, both state transfer protocols close the barrier, process the state *request* and re-open it. However, this is NOT done for state *responses* !
> The following issue could happen:
> - D requests the state from A
> - B multicasts #11
> - D receives the digest A:5, B:10, C:44 and (in parallel) B:11
> Scenario #1:
> - [NAKACK] D applies the digest (is 10 for B)
> - [NAKACK] D receives B:11 (is 11 now for B)
> - D delivers B:11 to the app, changes state
> - D sets state, overwrites the change made by B:11
> --> B:11 will *not* get retransmitted as the digest in NAKACK already has it: the change made by B:11 is lost !
> Scenario #2:
> - [NAKACK] D receives B:11 (is 11 now for B)
> - [NAKACK] D applies the digest: resets the digest for B to #10
> - D sets state
> - D delivers B:11 to the app, changes state
> --> B:11 will get retransmitted as the digest in NAKACK doesn't contain it
> --> B:11 changes state *again*: B:11 is delivered *twice* !
> So scenario #1 loses B:11 while scenario #2 delivers B:11 twice, which has to be prevented.
> SOLUTION: 
> - Close BARRIER before state response is handled (similar to what we do with a state request)
> - This way, either B:11 is handled and changes the digest in NAKACK and the app state *before* we set the digest in NAKACK and the app state, OR the digest is set in NAKACK and the app state is set from the state response and THEN B:11 is handled

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

        

From jira-events at lists.jboss.org  Mon Jul 20 09:33:29 2009
From: jira-events at lists.jboss.org (Werner van Mook (JIRA))
Date: Mon, 20 Jul 2009 09:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-90) Using enum and
 switch with hybernate and jboss caching annotations gives an error while
 deploying in jboss AS5.1
Message-ID: <1228424485.1248096809669.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Using enum and switch with hybernate and jboss caching annotations gives an error while deploying in jboss AS5.1
----------------------------------------------------------------------------------------------------------------

                 Key: JASSIST-90
                 URL: https://jira.jboss.org/jira/browse/JASSIST-90
             Project: Javassist
          Issue Type: Bug
         Environment: JBoss 5.1.0.GA  (according to javassist manifest version 3.9.0.GA which is not in versions list) Sun JDK/JRE build 1.6.0_11-b03 Windows XP 5.1, x86
            Reporter: Werner van Mook
            Assignee: Shigeru Chiba


In an entity bean of type Request (See source) a method is defined with a switch statement. The switch statement is using enum values in the case. The Request class has annotations @Entity and @Replicable and for some object methods @Id and @GeneratedValue.

In a class called HelperClass (See source) an enum is defined. The HelperClass has annotation @Replicable.

After compile with ant script (See source) and starting JBoss with "-c all" an VerifyError occurs (See stackTrace)

Changing the switch statement into a nested if / else block makes it work.

<---------src---------->

Request.java:

package entity;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

import org.jboss.cache.pojo.annotation.Replicable;

@Entity
@Replicable
public class Request {
	
	private long id;
	private String filename;
	
	
	public Request(){
	}

	/**
	 * @return the id
	 */
	@Id
	@GeneratedValue
	public long getId() {
		return id;
	}

	/**
	 * @param id the id to set
	 */
	public void setId(long id) {
		this.id = id;
	}

	/**
	 * @return the filename
	 */
	public String getFilename() {
		return filename;
	}

	/**
	 * @param filename the filename to set
	 */
	public void setFilename(String filename) {
		this.filename = filename;
	}

	@Override
	public String toString() {
		return "id: " + id + " filename: " + filename;
	}
	
	public void inform() {
		HelperClass help = new HelperClass();
		informDeviceStateWhileHavingFullLock(help);
	}
	
	private void informDeviceStateWhileHavingFullLock(HelperClass osDeviceState) {
		switch (osDeviceState.getRuntimeStateRange()) {		
			case PROBLEM_CONNECTING: 
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case PROBLEM_SENDING:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case CONNECTED:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case INVALID:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case INTERRUPTED:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case STOPPED:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			default:
				System.out.println("Device state default is always ignored");			
				break;
		}
	}
}

HelperClass.java

package entity;

import org.jboss.cache.pojo.annotation.Replicable;
import org.jboss.cache.pojo.annotation.Transient;


@Replicable
public class HelperClass {

	private RuntimeStateRange runtimeState = RuntimeStateRange.RESTING;
	
	public static enum RuntimeStateRange {
		OFFLINE, 
		CONNECTED, 
		PROBLEM, 
		PROBLEM_CONNECTING,
		PROBLEM_SENDING,
		INTERRUPTED,
		STOPPED,
		INVALID,
		RESTING,
		BUSY,
		INITIALIZING }; 
		
	public HelperClass() {
		System.out.println("HelperClass created.");
	}

	public int EnumgetRuntimeState() {
		return runtimeState.ordinal();
	}
	
	public RuntimeStateRange getRuntimeStateRange(){
		return runtimeState;
	}
}


<--------------------------END src --------------->

<-------------------Stack trace ------------------>
15:09:15,730 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
15:09:15,730 INFO  [ServerImpl] Release ID: JBoss [The Oracle] 5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)
15:09:15,730 INFO  [ServerImpl] Bootstrap URL: null
15:09:15,730 INFO  [ServerImpl] Home Dir: C:\Java\jboss-5.1.0.GA
15:09:15,730 INFO  [ServerImpl] Home URL: file:/C:/Java/jboss-5.1.0.GA/
15:09:15,730 INFO  [ServerImpl] Library URL: file:/C:/Java/jboss-5.1.0.GA/lib/
15:09:15,730 INFO  [ServerImpl] Patch URL: null
15:09:15,730 INFO  [ServerImpl] Common Base URL: file:/C:/Java/jboss-5.1.0.GA/common/
15:09:15,746 INFO  [ServerImpl] Common Library URL: file:/C:/Java/jboss-5.1.0.GA/common/lib/
15:09:15,746 INFO  [ServerImpl] Server Name: all
15:09:15,746 INFO  [ServerImpl] Server Base Dir: C:\Java\jboss-5.1.0.GA\server
15:09:15,746 INFO  [ServerImpl] Server Base URL: file:/C:/Java/jboss-5.1.0.GA/server/
15:09:15,746 INFO  [ServerImpl] Server Config URL: file:/C:/Java/jboss-5.1.0.GA/server/all/conf/
15:09:15,746 INFO  [ServerImpl] Server Home Dir: C:\Java\jboss-5.1.0.GA\server\all
15:09:15,746 INFO  [ServerImpl] Server Home URL: file:/C:/Java/jboss-5.1.0.GA/server/all/
15:09:15,746 INFO  [ServerImpl] Server Data Dir: C:\Java\jboss-5.1.0.GA\server\all\data
15:09:15,746 INFO  [ServerImpl] Server Library URL: file:/C:/Java/jboss-5.1.0.GA/server/all/lib/
15:09:15,746 INFO  [ServerImpl] Server Log Dir: C:\Java\jboss-5.1.0.GA\server\all\log
15:09:15,746 INFO  [ServerImpl] Server Native Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp\native
15:09:15,746 INFO  [ServerImpl] Server Temp Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp
15:09:15,746 INFO  [ServerImpl] Server Temp Deploy Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp\deploy
15:09:16,355 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Java/jboss-5.1.0.GA/server/all/conf/bootstrap.xml
15:09:16,886 INFO  [VFSCacheFactory] Initializing VFSCache [org.jboss.virtual.plugins.cache.CombinedVFSCache]
15:09:16,886 INFO  [VFSCacheFactory] Using VFSCache [CombinedVFSCache[real-cache: null]]
15:09:17,152 INFO  [CopyMechanism] VFS temp dir: C:\Java\jboss-5.1.0.GA\server\all\tmp
15:09:17,152 INFO  [ZipEntryContext] VFS force nested jars copy-mode is enabled.
15:09:18,043 INFO  [ServerInfo] Java version: 1.6.0_11,Sun Microsystems Inc.
15:09:18,043 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
15:09:18,043 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 11.0-b16,Sun Microsystems Inc.
15:09:18,043 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
15:09:18,043 INFO  [ServerInfo] VM arguments: -Djboss.home=C:/Java/jboss-5.1.0.GA -Djava.library.path=C:/Program Files/Java/jdk1.6.0_11/bin -Djava.endorsed.dirs=C:/Java/jboss-5.1.0.GA/lib/endorsed -Xms256m -Xmx512m -XX:MaxPermSize=256m -Djboss.partition.name=Wernie -Dfile.encoding=Cp1252 
15:09:18,105 INFO  [JMXKernel] Legacy JMX core initialized
15:09:19,652 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 453dd5[domain=default, server=default, name=all]
15:09:21,246 INFO  [WebService] Using RMI server codebase: http://HHDEV06:8083/
15:09:26,089 INFO  [NativeServerConfig] JBoss Web Services - Stack Native Core
15:09:26,089 INFO  [NativeServerConfig] 3.1.2.GA
15:09:26,886 INFO  [AttributeCallbackItem] Owner callback not implemented.
15:09:28,495 INFO  [LogNotificationListener] Adding notification listener for logging mbean "jboss.system:service=Logging,type=Log4jService" to server org.jboss.mx.server.MBeanServerImpl at 23d278[ defaultDomain='jboss' ]
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,182 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 1507654{vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/test_clustered_slsb.jar/}
15:09:40,182 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 1507654{vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/test_clustered_slsb.jar/}
15:09:41,322 INFO  [CorbaNamingService] CORBA Naming Started
15:09:45,869 INFO  [JMXConnectorServerService] JMX Connector server: service:jmx:rmi://HHDEV06/jndi/rmi://HHDEV06:1090/jmxconnector
15:09:46,103 INFO  [MailService] Mail Service bound to java:/Mail
15:09:46,681 INFO  [SnmpAgentService] SNMP agent going active
15:09:49,166 INFO  [Wernie] Initializing partition Wernie
15:09:49,291 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2335 (cluster=Wernie)
---------------------------------------------------------
15:09:49,416 INFO  [PlatformMBeanServerRegistration] JBossCache MBeans were successfully registered to the platform mbean server.
15:09:49,447 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2335 (cluster=Wernie-HAPartitionCache)
---------------------------------------------------------
15:09:51,369 INFO  [Wernie] Number of cluster members: 1
15:09:51,384 INFO  [Wernie] Other members: 0
15:09:51,462 INFO  [RPCManagerImpl] Received new cluster view: [192.168.100.98:2335|0] [192.168.100.98:2335]
15:09:51,462 INFO  [RPCManagerImpl] Cache local address is 192.168.100.98:2335
15:09:51,462 INFO  [RPCManagerImpl] state was retrieved successfully (in 2,02 seconds)
15:09:51,478 INFO  [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA
15:09:51,478 INFO  [Wernie] Fetching serviceState (will wait for 30000 milliseconds):
15:09:51,478 INFO  [Wernie] State could not be retrieved (we are the first member in group)
15:09:51,556 INFO  [HANamingService] Started HAJNDI bootstrap; jnpPort=1100, backlog=50, bindAddress=/0.0.0.0
15:09:51,572 INFO  [DetachedHANamingService$AutomaticDiscovery] Listening on /0.0.0.0:1102, group=230.0.0.4, HA-JNDI address=192.168.100.98:1100
15:09:52,494 INFO  [UnifiedInvokerHA] Service name is jboss:service=invoker,type=unifiedha
15:09:53,040 WARN  [JBossASSecurityMetadataStore] WARNING! POTENTIAL SECURITY RISK. It has been detected that the MessageSucker component which sucks messages from one node to another has not had its password changed from the installation default. Please see the JBoss Messaging user guide for instructions on how to do this.
15:09:53,072 WARN  [AnnotationCreator] No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
15:09:53,212 WARN  [AnnotationCreator] No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
15:09:53,290 INFO  [TransactionManagerService] JBossTS Transaction Service (JTA version - tag:JBOSSTS_4_6_1_GA) - JBoss Inc.
15:09:53,290 INFO  [TransactionManagerService] Setting up property manager MBean and JMX layer
15:09:54,337 INFO  [TransactionManagerService] Initializing recovery manager
15:09:54,478 INFO  [TransactionManagerService] Recovery manager configured
15:09:54,478 INFO  [TransactionManagerService] Binding TransactionManager JNDI Reference
15:09:54,525 INFO  [TransactionManagerService] Starting transaction recovery manager
15:09:55,025 INFO  [AprLifecycleListener] The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:/Program Files/Java/jdk1.6.0_11/bin
15:09:55,087 INFO  [Http11Protocol] Initializing Coyote HTTP/1.1 on http-0.0.0.0-8080
15:09:55,087 INFO  [AjpProtocol] Initializing Coyote AJP/1.3 on ajp-0.0.0.0-8009
15:09:55,103 INFO  [StandardService] Starting service jboss.web
15:09:55,118 INFO  [StandardEngine] Starting Servlet Engine: JBoss Web/2.1.3.GA
15:09:55,181 INFO  [Catalina] Server startup in 91 ms
15:09:55,197 INFO  [TomcatDeployment] deploy, ctxPath=/juddi
15:09:55,743 INFO  [RegistryServlet] Loading jUDDI configuration.
15:09:55,743 INFO  [RegistryServlet] Resources loaded from: /WEB-INF/juddi.properties
15:09:55,743 INFO  [RegistryServlet] Initializing jUDDI components.
15:09:55,962 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
15:09:56,009 INFO  [TomcatDeployment] deploy, ctxPath=/web-console
15:09:57,462 INFO  [TomcatDeployment] deploy, ctxPath=/jbossws
15:09:57,618 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jboss-local-jdbc.rar/META-INF/ra.xml
15:09:57,634 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jboss-xa-jdbc.rar/META-INF/ra.xml
15:09:57,665 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jms-ra.rar/META-INF/ra.xml
15:09:57,696 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/mail-ra.rar/META-INF/ra.xml
15:09:57,712 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/quartz-ra.rar/META-INF/ra.xml
15:09:57,806 INFO  [SimpleThreadPool] Job execution threads will use class loader of thread: main
15:09:57,853 INFO  [QuartzScheduler] Quartz Scheduler v.1.5.2 created.
15:09:57,853 INFO  [RAMJobStore] RAMJobStore initialized.
15:09:57,853 INFO  [StdSchedulerFactory] Quartz scheduler 'DefaultQuartzScheduler' initialized from default resource file in Quartz package: 'quartz.properties'
15:09:57,853 INFO  [StdSchedulerFactory] Quartz scheduler version: 1.5.2
15:09:57,853 INFO  [QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
15:09:58,368 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
15:09:58,915 INFO  [ServerPeer] JBoss Messaging 1.4.3.GA server [0] started
15:09:59,134 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2335 (cluster=MessagingPostOffice-CTRL)
---------------------------------------------------------
15:10:01,149 INFO  [GroupMember] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 52bb2d got new view [192.168.100.98:2335|0] [192.168.100.98:2335], old view is null
15:10:01,149 INFO  [GroupMember] I am (192.168.100.98:2335)
15:10:01,149 INFO  [GroupMember] New Members : 1 ([192.168.100.98:2335])
15:10:01,149 INFO  [GroupMember] All Members : 1 ([192.168.100.98:2335])
15:10:01,181 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:7900 (cluster=MessagingPostOffice-DATA)
---------------------------------------------------------
15:10:07,227 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
15:10:07,227 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at bfd4f6 started
15:10:07,258 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
15:10:07,258 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at 1c977ef started
15:10:07,274 INFO  [QueueService] Queue[/queue/DLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:10:07,305 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
15:10:07,305 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at 14647e5 started
15:10:07,305 INFO  [QueueService] Queue[/queue/ExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:10:07,461 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'
15:10:07,883 INFO  [JBossASKernel] Created KernelDeployment for: profileservice-secured.jar
15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3
15:10:07,883 INFO  [JBossASKernel]   with dependencies:
15:10:07,883 INFO  [JBossASKernel]   and demands:
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView
15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:07,883 INFO  [JBossASKernel]   and supplies:
15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.profileservice.spi.ProfileService
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureProfileService/remote
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureProfileService/remote-org.jboss.profileservice.spi.ProfileService
15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3) to KernelDeployment of: profileservice-secured.jar
15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3
15:10:07,883 INFO  [JBossASKernel]   with dependencies:
15:10:07,883 INFO  [JBossASKernel]   and demands:
15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:07,883 INFO  [JBossASKernel]   and supplies:
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureDeploymentManager/remote-org.jboss.deployers.spi.management.deploy.DeploymentManager
15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.deployers.spi.management.deploy.DeploymentManager
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureDeploymentManager/remote
15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3) to KernelDeployment of: profileservice-secured.jar
15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3
15:10:07,883 INFO  [JBossASKernel]   with dependencies:
15:10:07,883 INFO  [JBossASKernel]   and demands:
15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:07,883 INFO  [JBossASKernel]   and supplies:
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView
15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.deployers.spi.management.ManagementView
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote
15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3) to KernelDeployment of: profileservice-secured.jar
15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at f5f77{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 1bd9f3d{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 98fc6a{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:08,024 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3
15:10:08,039 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureDeploymentManager ejbName: SecureDeploymentManager
15:10:08,102 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	SecureDeploymentManager/remote - EJB3.x Default Remote Business Interface
	SecureDeploymentManager/remote-org.jboss.deployers.spi.management.deploy.DeploymentManager - EJB3.x Remote Business Interface

15:10:08,196 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3
15:10:08,196 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureManagementView ejbName: SecureManagementView
15:10:08,211 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	SecureManagementView/remote - EJB3.x Default Remote Business Interface
	SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView - EJB3.x Remote Business Interface

15:10:08,274 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3
15:10:08,274 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureProfileServiceBean ejbName: SecureProfileService
15:10:08,305 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	SecureProfileService/remote - EJB3.x Default Remote Business Interface
	SecureProfileService/remote-org.jboss.profileservice.spi.ProfileService - EJB3.x Remote Business Interface

15:10:08,414 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3
15:10:08,414 INFO  [JBossASKernel]   with dependencies:
15:10:08,414 INFO  [JBossASKernel]   and demands:
15:10:08,414 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:08,414 INFO  [JBossASKernel]   and supplies:
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local
15:10:08,414 INFO  [JBossASKernel] 	Class:service.ITestServiceBeanManagement
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/remote
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
15:10:08,414 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3) to KernelDeployment of: test_clustered_slsb.jar
15:10:08,414 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3
15:10:08,414 INFO  [JBossASKernel]   with dependencies:
15:10:08,414 INFO  [JBossASKernel]   and demands:
15:10:08,414 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
15:10:08,414 INFO  [JBossASKernel]   and supplies:
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestClusteredBean/remote
15:10:08,414 INFO  [JBossASKernel] 	Class:session.ITestClusteredBean
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestClusteredBean/remote-session.ITestClusteredBean
15:10:08,414 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3) to KernelDeployment of: test_clustered_slsb.jar
15:10:08,414 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at ad588a{name=jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:08,602 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:08,618 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:08,649 INFO  [PlatformMBeanServerRegistration] JBossCache MBeans were successfully registered to the platform mbean server.
15:10:08,711 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2353 (cluster=Wernie-UnistreamPojoCache)
---------------------------------------------------------
15:10:10,774 INFO  [RPCManagerImpl] Received new cluster view: [192.168.100.98:2353|0] [192.168.100.98:2353]
15:10:10,774 INFO  [RPCManagerImpl] Cache local address is 192.168.100.98:2353
15:10:10,774 INFO  [RPCManagerImpl] state was retrieved successfully (in 2,11 seconds)
15:10:10,774 INFO  [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:10,930 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3,type=ManagementInterface
15:10:10,930 INFO  [JBossASKernel]   with dependencies:
15:10:10,930 INFO  [JBossASKernel]   and demands:
15:10:10,930 INFO  [JBossASKernel] 	jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3
15:10:10,930 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:10,930 INFO  [JBossASKernel]   and supplies:
15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/local
15:10:10,930 INFO  [JBossASKernel] 	Class:service.ITestServiceBeanManagement
15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/remote
15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
15:10:10,930 INFO  [JBossASKernel] Installing bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3,type=ManagementInterface) into kernel
15:10:10,961 WARN  [UniStreamCacheListener] ::::  UniStreamCacheListener created  ::::
15:10:10,961 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:10,961 INFO  [STDOUT] Create of TestServiceBean
15:10:10,961 INFO  [EJBContainer] STARTED EJB: service.TestServiceBean ejbName: TestServiceBean
15:10:10,977 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	TestServiceBean/local - EJB3.x Default Local Business Interface
	TestServiceBean/local-service.ITestServiceBeanLocal - EJB3.x Local Business Interface

15:10:11,024 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3
15:10:11,024 INFO  [EJBContainer] STARTED EJB: session.TestClusteredBean ejbName: TestClusteredBean
15:10:11,071 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	TestClusteredBean/remote - EJB3.x Default Remote Business Interface
	TestClusteredBean/remote-session.ITestClusteredBean - EJB3.x Remote Business Interface

15:10:11,102 INFO  [PersistenceUnitDeployment] Starting persistence unit persistence.unit:unitName=#unistream
15:10:11,196 INFO  [Version] Hibernate Annotations 3.4.0.GA
15:10:11,227 INFO  [Environment] Hibernate 3.3.1.GA
15:10:11,242 INFO  [Environment] hibernate.properties not found
15:10:11,242 INFO  [Environment] Bytecode provider name : javassist
15:10:11,242 INFO  [Environment] using JDK 1.4 java.sql.Timestamp handling
15:10:11,383 INFO  [Version] Hibernate Commons Annotations 3.1.0.GA
15:10:11,383 INFO  [Version] Hibernate EntityManager 3.4.0.GA
15:10:11,430 INFO  [Ejb3Configuration] Processing PersistenceUnitInfo [
	name: unistream
	...]
15:10:11,461 WARN  [Ejb3Configuration] Persistence provider caller does not implement the EJB3 spec correctly. PersistenceUnitInfo.getNewTempClassLoader() is null.
15:10:11,570 INFO  [AnnotationBinder] Binding entity from annotated class: entity.Request
15:10:11,664 INFO  [EntityBinder] Bind entity entity.Request on table Request
15:10:11,680 ERROR [AbstractKernelController] Error installing to Start: name=persistence.unit:unitName=#unistream state=Create
java.lang.VerifyError: (class: entity/Request, method: informDeviceStateWhileHavingFullLock signature: (Lentity/HelperClass;)V) Unable to pop operand off an empty stack
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
	at java.lang.Class.getDeclaredMethods(Class.java:1791)
	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredMethodProperties(JavaXClass.java:89)
	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredProperties(JavaXClass.java:106)
	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredProperties(JavaXClass.java:98)
	at org.hibernate.cfg.AnnotationBinder.addElementsOfAClass(AnnotationBinder.java:1023)
	at org.hibernate.cfg.AnnotationBinder.getElementsToProcess(AnnotationBinder.java:859)
	at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:667)
	at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:546)
	at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:291)
	at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1148)
	at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1226)
	at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:173)
	at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:854)
	at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:425)
	at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:131)
	at org.jboss.jpa.deployment.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:301)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	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.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
	at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
	at org.jboss.Main.boot(Main.java:221)
	at org.jboss.Main$1.run(Main.java:556)
	at java.lang.Thread.run(Thread.java:619)
15:10:11,774 INFO  [TomcatDeployment] deploy, ctxPath=/admin-console
15:10:11,852 INFO  [config] Initializing Mojarra (1.2_12-b01-FCS) for context '/admin-console'
15:10:15,680 INFO  [TomcatDeployment] deploy, ctxPath=/
15:10:15,726 INFO  [TomcatDeployment] deploy, ctxPath=/jmx-console
15:10:15,883 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

DEPLOYMENTS IN ERROR:
  Deployment "persistence.unit:unitName=#unistream" is in error due to the following reason(s): java.lang.VerifyError: (class: entity/Request, method: informDeviceStateWhileHavingFullLock signature: (Lentity/HelperClass;)V) Unable to pop operand off an empty stack

15:10:15,883 INFO  [Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8080
15:10:15,914 INFO  [AjpProtocol] Starting Coyote AJP/1.3 on ajp-0.0.0.0-8009
15:10:15,930 INFO  [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 1m:184ms


<----------------------END Stack trace ----------------------->



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

        

From jira-events at lists.jboss.org  Mon Jul 20 08:59:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 20 Jul 2009 08:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1659) Create source
	distribution
In-Reply-To: <1154159.1245315667976.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <669924223.1248094769338.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1659.
------------------------------------

    Resolution: Done


added source-distro target to the trunk

> Create source distribution
> --------------------------
>
>                 Key: JBMESSAGING-1659
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1659
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Build System
>    Affects Versions: 2.0.0.beta2
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> JBoss Messaging build systems creates only binary distributions.
> We must also create source distributions which contains the source.
> An alternative is to always include the source in the distributions (the src dir is 4,4M and 1M when zipped)

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

        

From jira-events at lists.jboss.org  Mon Jul 20 08:59:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 20 Jul 2009 08:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1063889122.1248094769227.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476850#action_12476850 ] 

Tim Fox commented on JBMESSAGING-1664:
--------------------------------------

That may be true for some databases but we can't assume they all support database cursors

> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 08:57:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 20 Jul 2009 08:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <853455039.1248094649446.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476849#action_12476849 ] 

Howard Gao commented on JBMESSAGING-1664:
-----------------------------------------

Yes, I'm thinking about it. The changes makes the ResultSet become large, but not in the JBM server, rather in the DB server.
We just iterate through the result set and only store the needed records. So it shouldn't be a memory burden for JBM server.



> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 09:52:30 2009
From: jira-events at lists.jboss.org (Werner van Mook (JIRA))
Date: Mon, 20 Jul 2009 09:52:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JASSIST-90) Using enum and
 switch with hybernate and jboss caching annotations gives an error while
 deploying in jboss AS5.1
In-Reply-To: <1228424485.1248096809669.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <874135220.1248097950639.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Werner van Mook updated JASSIST-90:
-----------------------------------

    Description: 
In an entity bean of type Request (See source) a method is defined with a switch statement. The switch statement is using enum values in the case. The Request class has annotations @Entity and @Replicable and for some object methods @Id and @GeneratedValue.

In a class called HelperClass (See source) an enum is defined. The HelperClass has annotation @Replicable.

After compile with ant script (See source) and starting JBoss with "-c all" an VerifyError occurs (See stackTrace)

Changing the switch statement into a nested if / else block makes it work.

<---------src---------->

Request.java:

package entity;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

import org.jboss.cache.pojo.annotation.Replicable;

@Entity
@Replicable
public class Request {
	
	private long id;
	private String filename;
	
	
	public Request(){
	}

	/**
	 * @return the id
	 */
	@Id
	@GeneratedValue
	public long getId() {
		return id;
	}

	/**
	 * @param id the id to set
	 */
	public void setId(long id) {
		this.id = id;
	}

	/**
	 * @return the filename
	 */
	public String getFilename() {
		return filename;
	}

	/**
	 * @param filename the filename to set
	 */
	public void setFilename(String filename) {
		this.filename = filename;
	}

	@Override
	public String toString() {
		return "id: " + id + " filename: " + filename;
	}
	
	public void inform() {
		HelperClass help = new HelperClass();
		informDeviceStateWhileHavingFullLock(help);
	}
	
	private void informDeviceStateWhileHavingFullLock(HelperClass osDeviceState) {
		switch (osDeviceState.getRuntimeStateRange()) {		
			case PROBLEM_CONNECTING: 
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case PROBLEM_SENDING:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case CONNECTED:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case INVALID:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case INTERRUPTED:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case STOPPED:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			default:
				System.out.println("Device state default is always ignored");			
				break;
		}
	}
}

HelperClass.java

package entity;

import org.jboss.cache.pojo.annotation.Replicable;
import org.jboss.cache.pojo.annotation.Transient;


@Replicable
public class HelperClass {

	private RuntimeStateRange runtimeState = RuntimeStateRange.RESTING;
	
	public static enum RuntimeStateRange {
		OFFLINE, 
		CONNECTED, 
		PROBLEM, 
		PROBLEM_CONNECTING,
		PROBLEM_SENDING,
		INTERRUPTED,
		STOPPED,
		INVALID,
		RESTING,
		BUSY,
		INITIALIZING }; 
		
	public HelperClass() {
		System.out.println("HelperClass created.");
	}

	public int EnumgetRuntimeState() {
		return runtimeState.ordinal();
	}
	
	public RuntimeStateRange getRuntimeStateRange(){
		return runtimeState;
	}
}


<--------------------------END src --------------->

<-------------------Stack trace ------------------>
15:09:15,730 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
15:09:15,730 INFO  [ServerImpl] Release ID: JBoss [The Oracle] 5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)
15:09:15,730 INFO  [ServerImpl] Bootstrap URL: null
15:09:15,730 INFO  [ServerImpl] Home Dir: C:\Java\jboss-5.1.0.GA
15:09:15,730 INFO  [ServerImpl] Home URL: file:/C:/Java/jboss-5.1.0.GA/
15:09:15,730 INFO  [ServerImpl] Library URL: file:/C:/Java/jboss-5.1.0.GA/lib/
15:09:15,730 INFO  [ServerImpl] Patch URL: null
15:09:15,730 INFO  [ServerImpl] Common Base URL: file:/C:/Java/jboss-5.1.0.GA/common/
15:09:15,746 INFO  [ServerImpl] Common Library URL: file:/C:/Java/jboss-5.1.0.GA/common/lib/
15:09:15,746 INFO  [ServerImpl] Server Name: all
15:09:15,746 INFO  [ServerImpl] Server Base Dir: C:\Java\jboss-5.1.0.GA\server
15:09:15,746 INFO  [ServerImpl] Server Base URL: file:/C:/Java/jboss-5.1.0.GA/server/
15:09:15,746 INFO  [ServerImpl] Server Config URL: file:/C:/Java/jboss-5.1.0.GA/server/all/conf/
15:09:15,746 INFO  [ServerImpl] Server Home Dir: C:\Java\jboss-5.1.0.GA\server\all
15:09:15,746 INFO  [ServerImpl] Server Home URL: file:/C:/Java/jboss-5.1.0.GA/server/all/
15:09:15,746 INFO  [ServerImpl] Server Data Dir: C:\Java\jboss-5.1.0.GA\server\all\data
15:09:15,746 INFO  [ServerImpl] Server Library URL: file:/C:/Java/jboss-5.1.0.GA/server/all/lib/
15:09:15,746 INFO  [ServerImpl] Server Log Dir: C:\Java\jboss-5.1.0.GA\server\all\log
15:09:15,746 INFO  [ServerImpl] Server Native Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp\native
15:09:15,746 INFO  [ServerImpl] Server Temp Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp
15:09:15,746 INFO  [ServerImpl] Server Temp Deploy Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp\deploy
15:09:16,355 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Java/jboss-5.1.0.GA/server/all/conf/bootstrap.xml
15:09:16,886 INFO  [VFSCacheFactory] Initializing VFSCache [org.jboss.virtual.plugins.cache.CombinedVFSCache]
15:09:16,886 INFO  [VFSCacheFactory] Using VFSCache [CombinedVFSCache[real-cache: null]]
15:09:17,152 INFO  [CopyMechanism] VFS temp dir: C:\Java\jboss-5.1.0.GA\server\all\tmp
15:09:17,152 INFO  [ZipEntryContext] VFS force nested jars copy-mode is enabled.
15:09:18,043 INFO  [ServerInfo] Java version: 1.6.0_11,Sun Microsystems Inc.
15:09:18,043 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
15:09:18,043 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 11.0-b16,Sun Microsystems Inc.
15:09:18,043 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
15:09:18,043 INFO  [ServerInfo] VM arguments: -Djboss.home=C:/Java/jboss-5.1.0.GA -Djava.library.path=C:/Program Files/Java/jdk1.6.0_11/bin -Djava.endorsed.dirs=C:/Java/jboss-5.1.0.GA/lib/endorsed -Xms256m -Xmx512m -XX:MaxPermSize=256m -Djboss.partition.name=Wernie -Dfile.encoding=Cp1252 
15:09:18,105 INFO  [JMXKernel] Legacy JMX core initialized
15:09:19,652 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 453dd5[domain=default, server=default, name=all]
15:09:21,246 INFO  [WebService] Using RMI server codebase: http://HHDEV06:8083/
15:09:26,089 INFO  [NativeServerConfig] JBoss Web Services - Stack Native Core
15:09:26,089 INFO  [NativeServerConfig] 3.1.2.GA
15:09:26,886 INFO  [AttributeCallbackItem] Owner callback not implemented.
15:09:28,495 INFO  [LogNotificationListener] Adding notification listener for logging mbean "jboss.system:service=Logging,type=Log4jService" to server org.jboss.mx.server.MBeanServerImpl at 23d278[ defaultDomain='jboss' ]
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,182 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 1507654{vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/test_clustered_slsb.jar/}
15:09:40,182 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 1507654{vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/test_clustered_slsb.jar/}
15:09:41,322 INFO  [CorbaNamingService] CORBA Naming Started
15:09:45,869 INFO  [JMXConnectorServerService] JMX Connector server: service:jmx:rmi://HHDEV06/jndi/rmi://HHDEV06:1090/jmxconnector
15:09:46,103 INFO  [MailService] Mail Service bound to java:/Mail
15:09:46,681 INFO  [SnmpAgentService] SNMP agent going active
15:09:49,166 INFO  [Wernie] Initializing partition Wernie
15:09:49,291 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2335 (cluster=Wernie)
---------------------------------------------------------
15:09:49,416 INFO  [PlatformMBeanServerRegistration] JBossCache MBeans were successfully registered to the platform mbean server.
15:09:49,447 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2335 (cluster=Wernie-HAPartitionCache)
---------------------------------------------------------
15:09:51,369 INFO  [Wernie] Number of cluster members: 1
15:09:51,384 INFO  [Wernie] Other members: 0
15:09:51,462 INFO  [RPCManagerImpl] Received new cluster view: [192.168.100.98:2335|0] [192.168.100.98:2335]
15:09:51,462 INFO  [RPCManagerImpl] Cache local address is 192.168.100.98:2335
15:09:51,462 INFO  [RPCManagerImpl] state was retrieved successfully (in 2,02 seconds)
15:09:51,478 INFO  [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA
15:09:51,478 INFO  [Wernie] Fetching serviceState (will wait for 30000 milliseconds):
15:09:51,478 INFO  [Wernie] State could not be retrieved (we are the first member in group)
15:09:51,556 INFO  [HANamingService] Started HAJNDI bootstrap; jnpPort=1100, backlog=50, bindAddress=/0.0.0.0
15:09:51,572 INFO  [DetachedHANamingService$AutomaticDiscovery] Listening on /0.0.0.0:1102, group=230.0.0.4, HA-JNDI address=192.168.100.98:1100
15:09:52,494 INFO  [UnifiedInvokerHA] Service name is jboss:service=invoker,type=unifiedha
15:09:53,040 WARN  [JBossASSecurityMetadataStore] WARNING! POTENTIAL SECURITY RISK. It has been detected that the MessageSucker component which sucks messages from one node to another has not had its password changed from the installation default. Please see the JBoss Messaging user guide for instructions on how to do this.
15:09:53,072 WARN  [AnnotationCreator] No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
15:09:53,212 WARN  [AnnotationCreator] No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
15:09:53,290 INFO  [TransactionManagerService] JBossTS Transaction Service (JTA version - tag:JBOSSTS_4_6_1_GA) - JBoss Inc.
15:09:53,290 INFO  [TransactionManagerService] Setting up property manager MBean and JMX layer
15:09:54,337 INFO  [TransactionManagerService] Initializing recovery manager
15:09:54,478 INFO  [TransactionManagerService] Recovery manager configured
15:09:54,478 INFO  [TransactionManagerService] Binding TransactionManager JNDI Reference
15:09:54,525 INFO  [TransactionManagerService] Starting transaction recovery manager
15:09:55,025 INFO  [AprLifecycleListener] The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:/Program Files/Java/jdk1.6.0_11/bin
15:09:55,087 INFO  [Http11Protocol] Initializing Coyote HTTP/1.1 on http-0.0.0.0-8080
15:09:55,087 INFO  [AjpProtocol] Initializing Coyote AJP/1.3 on ajp-0.0.0.0-8009
15:09:55,103 INFO  [StandardService] Starting service jboss.web
15:09:55,118 INFO  [StandardEngine] Starting Servlet Engine: JBoss Web/2.1.3.GA
15:09:55,181 INFO  [Catalina] Server startup in 91 ms
15:09:55,197 INFO  [TomcatDeployment] deploy, ctxPath=/juddi
15:09:55,743 INFO  [RegistryServlet] Loading jUDDI configuration.
15:09:55,743 INFO  [RegistryServlet] Resources loaded from: /WEB-INF/juddi.properties
15:09:55,743 INFO  [RegistryServlet] Initializing jUDDI components.
15:09:55,962 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
15:09:56,009 INFO  [TomcatDeployment] deploy, ctxPath=/web-console
15:09:57,462 INFO  [TomcatDeployment] deploy, ctxPath=/jbossws
15:09:57,618 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jboss-local-jdbc.rar/META-INF/ra.xml
15:09:57,634 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jboss-xa-jdbc.rar/META-INF/ra.xml
15:09:57,665 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jms-ra.rar/META-INF/ra.xml
15:09:57,696 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/mail-ra.rar/META-INF/ra.xml
15:09:57,712 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/quartz-ra.rar/META-INF/ra.xml
15:09:57,806 INFO  [SimpleThreadPool] Job execution threads will use class loader of thread: main
15:09:57,853 INFO  [QuartzScheduler] Quartz Scheduler v.1.5.2 created.
15:09:57,853 INFO  [RAMJobStore] RAMJobStore initialized.
15:09:57,853 INFO  [StdSchedulerFactory] Quartz scheduler 'DefaultQuartzScheduler' initialized from default resource file in Quartz package: 'quartz.properties'
15:09:57,853 INFO  [StdSchedulerFactory] Quartz scheduler version: 1.5.2
15:09:57,853 INFO  [QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
15:09:58,368 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
15:09:58,915 INFO  [ServerPeer] JBoss Messaging 1.4.3.GA server [0] started
15:09:59,134 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2335 (cluster=MessagingPostOffice-CTRL)
---------------------------------------------------------
15:10:01,149 INFO  [GroupMember] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 52bb2d got new view [192.168.100.98:2335|0] [192.168.100.98:2335], old view is null
15:10:01,149 INFO  [GroupMember] I am (192.168.100.98:2335)
15:10:01,149 INFO  [GroupMember] New Members : 1 ([192.168.100.98:2335])
15:10:01,149 INFO  [GroupMember] All Members : 1 ([192.168.100.98:2335])
15:10:01,181 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:7900 (cluster=MessagingPostOffice-DATA)
---------------------------------------------------------
15:10:07,227 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
15:10:07,227 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at bfd4f6 started
15:10:07,258 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
15:10:07,258 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at 1c977ef started
15:10:07,274 INFO  [QueueService] Queue[/queue/DLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:10:07,305 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
15:10:07,305 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at 14647e5 started
15:10:07,305 INFO  [QueueService] Queue[/queue/ExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:10:07,461 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'
15:10:07,883 INFO  [JBossASKernel] Created KernelDeployment for: profileservice-secured.jar
15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3
15:10:07,883 INFO  [JBossASKernel]   with dependencies:
15:10:07,883 INFO  [JBossASKernel]   and demands:
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView
15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:07,883 INFO  [JBossASKernel]   and supplies:
15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.profileservice.spi.ProfileService
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureProfileService/remote
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureProfileService/remote-org.jboss.profileservice.spi.ProfileService
15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3) to KernelDeployment of: profileservice-secured.jar
15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3
15:10:07,883 INFO  [JBossASKernel]   with dependencies:
15:10:07,883 INFO  [JBossASKernel]   and demands:
15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:07,883 INFO  [JBossASKernel]   and supplies:
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureDeploymentManager/remote-org.jboss.deployers.spi.management.deploy.DeploymentManager
15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.deployers.spi.management.deploy.DeploymentManager
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureDeploymentManager/remote
15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3) to KernelDeployment of: profileservice-secured.jar
15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3
15:10:07,883 INFO  [JBossASKernel]   with dependencies:
15:10:07,883 INFO  [JBossASKernel]   and demands:
15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:07,883 INFO  [JBossASKernel]   and supplies:
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView
15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.deployers.spi.management.ManagementView
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote
15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3) to KernelDeployment of: profileservice-secured.jar
15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at f5f77{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 1bd9f3d{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 98fc6a{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:08,024 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3
15:10:08,039 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureDeploymentManager ejbName: SecureDeploymentManager
15:10:08,102 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	SecureDeploymentManager/remote - EJB3.x Default Remote Business Interface
	SecureDeploymentManager/remote-org.jboss.deployers.spi.management.deploy.DeploymentManager - EJB3.x Remote Business Interface

15:10:08,196 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3
15:10:08,196 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureManagementView ejbName: SecureManagementView
15:10:08,211 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	SecureManagementView/remote - EJB3.x Default Remote Business Interface
	SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView - EJB3.x Remote Business Interface

15:10:08,274 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3
15:10:08,274 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureProfileServiceBean ejbName: SecureProfileService
15:10:08,305 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	SecureProfileService/remote - EJB3.x Default Remote Business Interface
	SecureProfileService/remote-org.jboss.profileservice.spi.ProfileService - EJB3.x Remote Business Interface

15:10:08,414 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3
15:10:08,414 INFO  [JBossASKernel]   with dependencies:
15:10:08,414 INFO  [JBossASKernel]   and demands:
15:10:08,414 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:08,414 INFO  [JBossASKernel]   and supplies:
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local
15:10:08,414 INFO  [JBossASKernel] 	Class:service.ITestServiceBeanManagement
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/remote
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
15:10:08,414 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3) to KernelDeployment of: test_clustered_slsb.jar
15:10:08,414 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3
15:10:08,414 INFO  [JBossASKernel]   with dependencies:
15:10:08,414 INFO  [JBossASKernel]   and demands:
15:10:08,414 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
15:10:08,414 INFO  [JBossASKernel]   and supplies:
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestClusteredBean/remote
15:10:08,414 INFO  [JBossASKernel] 	Class:session.ITestClusteredBean
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestClusteredBean/remote-session.ITestClusteredBean
15:10:08,414 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3) to KernelDeployment of: test_clustered_slsb.jar
15:10:08,414 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at ad588a{name=jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:08,602 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:08,618 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:08,649 INFO  [PlatformMBeanServerRegistration] JBossCache MBeans were successfully registered to the platform mbean server.
15:10:08,711 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2353 (cluster=Wernie-UnistreamPojoCache)
---------------------------------------------------------
15:10:10,774 INFO  [RPCManagerImpl] Received new cluster view: [192.168.100.98:2353|0] [192.168.100.98:2353]
15:10:10,774 INFO  [RPCManagerImpl] Cache local address is 192.168.100.98:2353
15:10:10,774 INFO  [RPCManagerImpl] state was retrieved successfully (in 2,11 seconds)
15:10:10,774 INFO  [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:10,930 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3,type=ManagementInterface
15:10:10,930 INFO  [JBossASKernel]   with dependencies:
15:10:10,930 INFO  [JBossASKernel]   and demands:
15:10:10,930 INFO  [JBossASKernel] 	jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3
15:10:10,930 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:10,930 INFO  [JBossASKernel]   and supplies:
15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/local
15:10:10,930 INFO  [JBossASKernel] 	Class:service.ITestServiceBeanManagement
15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/remote
15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
15:10:10,930 INFO  [JBossASKernel] Installing bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3,type=ManagementInterface) into kernel
15:10:10,961 WARN  [UniStreamCacheListener] ::::  UniStreamCacheListener created  ::::
15:10:10,961 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:10,961 INFO  [STDOUT] Create of TestServiceBean
15:10:10,961 INFO  [EJBContainer] STARTED EJB: service.TestServiceBean ejbName: TestServiceBean
15:10:10,977 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	TestServiceBean/local - EJB3.x Default Local Business Interface
	TestServiceBean/local-service.ITestServiceBeanLocal - EJB3.x Local Business Interface

15:10:11,024 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3
15:10:11,024 INFO  [EJBContainer] STARTED EJB: session.TestClusteredBean ejbName: TestClusteredBean
15:10:11,071 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	TestClusteredBean/remote - EJB3.x Default Remote Business Interface
	TestClusteredBean/remote-session.ITestClusteredBean - EJB3.x Remote Business Interface

15:10:11,102 INFO  [PersistenceUnitDeployment] Starting persistence unit persistence.unit:unitName=#unistream
15:10:11,196 INFO  [Version] Hibernate Annotations 3.4.0.GA
15:10:11,227 INFO  [Environment] Hibernate 3.3.1.GA
15:10:11,242 INFO  [Environment] hibernate.properties not found
15:10:11,242 INFO  [Environment] Bytecode provider name : javassist
15:10:11,242 INFO  [Environment] using JDK 1.4 java.sql.Timestamp handling
15:10:11,383 INFO  [Version] Hibernate Commons Annotations 3.1.0.GA
15:10:11,383 INFO  [Version] Hibernate EntityManager 3.4.0.GA
15:10:11,430 INFO  [Ejb3Configuration] Processing PersistenceUnitInfo [
	name: unistream
	...]
15:10:11,461 WARN  [Ejb3Configuration] Persistence provider caller does not implement the EJB3 spec correctly. PersistenceUnitInfo.getNewTempClassLoader() is null.
15:10:11,570 INFO  [AnnotationBinder] Binding entity from annotated class: entity.Request
15:10:11,664 INFO  [EntityBinder] Bind entity entity.Request on table Request
15:10:11,680 ERROR [AbstractKernelController] Error installing to Start: name=persistence.unit:unitName=#unistream state=Create
java.lang.VerifyError: (class: entity/Request, method: informDeviceStateWhileHavingFullLock signature: (Lentity/HelperClass;)V) Unable to pop operand off an empty stack
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
	at java.lang.Class.getDeclaredMethods(Class.java:1791)
	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredMethodProperties(JavaXClass.java:89)
	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredProperties(JavaXClass.java:106)
	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredProperties(JavaXClass.java:98)
	at org.hibernate.cfg.AnnotationBinder.addElementsOfAClass(AnnotationBinder.java:1023)
	at org.hibernate.cfg.AnnotationBinder.getElementsToProcess(AnnotationBinder.java:859)
	at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:667)
	at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:546)
	at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:291)
	at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1148)
	at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1226)
	at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:173)
	at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:854)
	at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:425)
	at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:131)
	at org.jboss.jpa.deployment.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:301)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	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.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
	at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
	at org.jboss.Main.boot(Main.java:221)
	at org.jboss.Main$1.run(Main.java:556)
	at java.lang.Thread.run(Thread.java:619)
15:10:11,774 INFO  [TomcatDeployment] deploy, ctxPath=/admin-console
15:10:11,852 INFO  [config] Initializing Mojarra (1.2_12-b01-FCS) for context '/admin-console'
15:10:15,680 INFO  [TomcatDeployment] deploy, ctxPath=/
15:10:15,726 INFO  [TomcatDeployment] deploy, ctxPath=/jmx-console
15:10:15,883 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

DEPLOYMENTS IN ERROR:
  Deployment "persistence.unit:unitName=#unistream" is in error due to the following reason(s): java.lang.VerifyError: (class: entity/Request, method: informDeviceStateWhileHavingFullLock signature: (Lentity/HelperClass;)V) Unable to pop operand off an empty stack

15:10:15,883 INFO  [Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8080
15:10:15,914 INFO  [AjpProtocol] Starting Coyote AJP/1.3 on ajp-0.0.0.0-8009
15:10:15,930 INFO  [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 1m:184ms


<----------------------END Stack trace ----------------------->



<----------------------- Ant file ------------------------->
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE project [
	<!ENTITY properties SYSTEM "../../../unispool7/config/buildfiles/properties.xml">
]>
<project default="deploy2Jboss" name="TestClusteredSessionBean" basedir="../..">

	<!-- read the properties from file -->
	&properties;

	<target name="prepare">
		<path id="classpath">
			<path refid="jboss.aop.classpath"/>
			<path refid="jboss.class.path"/>
			<pathelement path="bin"/>
		</path>
	</target>

	<target name="compile" depends="prepare">
		<delete dir="bin"/>
		<mkdir dir="bin"/>
		<javac srcdir="src" destdir="bin" deprecation="on" optimize="off" includes="**">
			<classpath refid="classpath"/>
		</javac>

		<copy todir="bin" filtering="no">
			<fileset dir="config/properties">
				<include name="**/*.properties"/>
			</fileset>
			<fileset dir="config">
				<include name="**/persistence.xml"/>
				<include name="**/unistream-pojo-cache-jboss-beans.xml"/>
			</fileset>
		</copy>
	</target>

	<target name="aopc" depends="compile">
		<unjar src="${jbossServerLib}/jbosscache-pojo.jar" dest="bin">
			<mapper type="flatten"/>
			<patternset>
        		<include name="**/pojocache-aop.xml"/>
    		</patternset>
		</unjar>
		<aopc compilerclasspathref="classpath" classpathref="classpath" verbose="true">
			<classpath path="bin"/>
			<src path="bin"/>
			<aoppath path="bin/pojocache-aop.xml"/>
			<aopclasspath path="bin"/>
		</aopc>
	</target>

	<target name="package-server-jar" depends="aopc" description="Create JAR File">
		<jar destfile="build/test_clustered_slsb.jar">
			<fileset dir="bin">
                <include name="**/*.*"/>
                <exclude name="**/Main.*"/>
                <exclude name="**/jndi.properties"/>
                <exclude name="**/pojocache-aop.xml"/>
			</fileset>
		</jar>
	</target>

	<target name="run-compile-time" depends="aopc">
		<java fork="yes" failOnError="true" className="Main">
			<sysproperty key="jboss.aop.path" value="bin/pojocache-aop.xml"/>
			<sysproperty key="jboss.aop.class.path" value="bin"/>
			<classpath refid="classpath"/>
		</java>
	</target>
	
	<target name="deploy2Jboss" depends="package-server-jar" description="Deploy the JAR File to JBoss">
		<copy file="build/test_clustered_slsb.jar" tofile="C:\Java\jboss-5.1.0.GA\server\all\deploy\test_clustered_slsb.jar"/>
	</target>

</project>






The properties file used by ant:





<!-- Read in the environment variables -->
<property environment="env"/>

<!-- Inits the properties -->
<tstamp/>

<!-- needed for if, switch tasks -->
<taskdef resource="net/sf/antcontrib/antcontrib.properties"/>
<taskdef resource="net/sf/antcontrib/antlib.xml"/>

<!-- base directories -->
<property name="src" location="${basedir}/src"/>
<property name="conf" location="${basedir}/config"/>
<property name="build" location="${basedir}/build"/>
<property name="dist" location="${basedir}/dist"/>
<property name="dist-obfuscated" location="${basedir}/dist-obfuscated"/>
<property name="ext" location="${basedir}/ext"/>
<property name="app" value="com/hollandhouse/unistream"/>

<!-- src directories -->
<property name="src" location="${src}"/>
<property name="HhLog4j" location="${src}/com/hollandhouse/unistream/framework/log/log4j/"/>

<!-- conf directories -->
<property name="conf-xml" location="${conf}/XML"/>
<property name="conf-jboss" location="${conf}/JBoss"/>
<property name="conf-properties" location="${conf}/properties"/>
<property name="conf-properties-server" location="${conf-properties}/server"/>
<property name="conf-properties-agent" location="${conf-properties}/agent"/>
<property name="conf-mergefiles" location="${conf}/mergefiles"/>
<property name="conf-buildfiles" location="${conf}/buildfiles"/>
<property name="conf-cache" location="${conf}/cache"/>

<!-- build directories -->
<property name="build-generated" location="${build}/generated"/>
<property name="generated.java.dir" value="${build-generated}"/>
<property name="build-classes" location="${build}/classes"/>
<property name="build-resources" location="${build}/resources"/>
<property name="build-doc" location="${build}/doc"/>
<property name="build-web" location="${build}/web"/>

<!-- file names -->
<property name="ejb-file" value="unistream-ejb3.jar"/>
<property name="ejb-agent-file" value="unistream-agent.jar"/>
<property name="sar-file" value="unistream.sar"/>
<property name="sar-agent-file" value="unistream-agent.sar"/>
<property name="entities-jar-file" value="entities.jar"/>
<property name="jar-entities-agent-file" value="entities-agent.jar"/>
<property name="war-file" value="unistream.war"/>
<property name="jar-hhlog4j-file" value="hhlog4j.jar"/>
<property name="xml-hhlog4j-file" value="log4j_unistream.xml"/>
<property name="common-file" value="unistream-framework.jar"/>
<property name="cli-file" value="unistream-cli.jar"/>
<property name="ear-file" value="unistream.ear"/>
<property name="ear-agent-file" value="unistream-agent.ear"/>
<property name="swing-gui-file" value="unistream-swing-gui.jar"/>
<property name="swing-gui-doc-file" value="unistream-swing-gui-doc.zip"/>
<property name="testpage-file" value="UNISTREAM-TESTFILE"/>
<property name="usPojoCache-file" value="unistream-pojo-cache-jboss-beans.xml"/>

<!-- build test directories -->
<property name="build-tests" location="${build}/tests"/>
<property name="build-reports" location="${build}/reports"/>

<!-- jboss settings main -->
<property name="jbossServerProfile" value="unistream_main"/>

<property name="jbossServer" location="${env.JBOSS_HOME}/server/${jbossServerProfile}"/>
<property name="jbossDeploy" location="${jbossServer}/deploy"/>
<property name="jbossServerLib" location="${jbossServer}/lib"/>
<property name="jbossConfig" location="${jbossServer}/conf"/>

<!-- jboss settings agent -->
<property name="jbossAgentProfile" value="unistream_agent"/>

<property name="jbossAgent" location="${env.JBOSS_HOME}/server/${jbossAgentProfile}"/>
<property name="jbossAgentDeploy" location="${jbossAgent}/deploy"/>
<property name="jbossAgentLib" location="${jbossAgent}/lib"/>
<property name="jbossAgentConfig" location="${jbossAgent}/conf"/>

<!-- jboss settings common -->
<property name="jbossLib" location="${env.JBOSS_HOME}/lib"/>
<property name="jbossClientLib" value="${env.JBOSS_HOME}/client"/>
<property name="jbossCommonLib" location="${env.JBOSS_HOME}/common/lib"/>

<!--        <property name="jbossDataSource" value="java:/mysqlDS"/>
<property name="jbossDataSourceMapping" value="mySQL"/> -->
<property name="jbossDataSource" value="java:/DefaultDS"/>
<property name="jbossDataSourceMapping" value="Hypersonic SQL"/>

<!-- Temp General manifest file -->
<property name="manifest-general" location="${build}/manifest_gen.txt"/>
<!-- Temp ClassPath manifest file -->
<property name="manifest-classpath" location="${build}/manifest_cp.txt"/>

<property name="version-file" value="unistream-version"/>

<!--  jboss properties files -->
<property name="xml-hhlog4j-path" location="${conf-properties-server}/${xml-hhlog4j-file}"/>
<property name="xml-hhlog4j-agent-path" location="${conf-properties-agent}/${xml-hhlog4j-file}"/>

<!-- setup the project class paths -->

<path id="jboss.class.path">
	<fileset dir="${jbossLib}">
		<include name="*.jar"/>
	</fileset>
	<fileset dir="${env.JBOSS_HOME}/client">
		<include name="*.jar"/>
	</fileset>
	<fileset dir="${jbossCommonLib}">
		<include name="*.jar"/>
	</fileset>
	<fileset dir="${jbossServerLib}">
		<include name="*.jar"/>
	</fileset>
</path>

<path id="ext.class.path">
	<path refid="jboss.class.path"/>
	<fileset dir="${ext}">
		<include name="**/*.jar"/>
	</fileset>
</path>

<path id="jboss.aop.classpath">
	<fileset dir="${jbossLib}">
		<include name="jboss-aop.jar"/>
	</fileset>
</path>

<!-- setup the project class paths -->
<path id="project.class.path">
	<path refid="ext.class.path"/>
	<path refid="jboss.aop.classpath"/>
</path>

<!-- Define the JBoss AOP compiler Ant task -->
<taskdef name="aopc" classname="org.jboss.aop.ant.AopC" classpathref="jboss.aop.classpath"/>

<path id="junit.test.class.path">
	<path refid="ext.class.path"/>
	<fileset dir="${dist}">
		<include name="*.jar"/>
		<include name="*.sar"/>
		<exclude name="*-agent.*"/>
	</fileset>
	<pathelement location="${conf-properties}"/>
	<pathelement location="${build-classes}"/>
</path>

<!-- Project Libraries -->

<property name="gui-jar-path" value="${basedir}/unistreamgui.jar"/>

<path id="library.gui_jars.classpath">
	<pathelement location="${jbossClientLib}/commons-logging.jar"/>
	<pathelement location="${jbossClientLib}/concurrent.jar"/>
	<pathelement location="${jbossClientLib}/ejb3-persistence.jar"/>
	<pathelement location="${jbossClientLib}/hibernate-annotations.jar"/>
	<pathelement location="${jbossClientLib}/javassist.jar"/>
	<pathelement location="${jbossClientLib}/jbossall-client.jar"/>
	<pathelement location="${jbossClientLib}/jboss-aop-client.jar"/>
	<pathelement location="${jbossClientLib}/jboss-aspect-jdk50-client.jar"/>
	<pathelement location="${jbossClientLib}/jboss-common-core.jar"/>
	<pathelement location="${jbossClientLib}/jboss-ejb3-common-client.jar"/>
	<pathelement location="${jbossClientLib}/jboss-ejb3-core-client.jar"/>
	<pathelement location="${jbossClientLib}/jboss-ejb3-ext-api.jar"/>
	<pathelement location="${jbossClientLib}/jboss-ejb3-ext-api-impl.jar"/>
	<pathelement location="${jbossClientLib}/jboss-ejb3-proxy-impl-client.jar"/>
	<pathelement location="${jbossClientLib}/jboss-ejb3-proxy-spi-client.jar"/>
	<pathelement location="${jbossClientLib}/jboss-ejb3-security-client.jar"/>
	<pathelement location="${jbossClientLib}/jboss-integration.jar"/>
	<pathelement location="${jbossClientLib}/jboss-javaee.jar"/>
	<pathelement location="${jbossClientLib}/jboss-logging-log4j.jar"/>
	<pathelement location="${jbossClientLib}/jboss-logging-spi.jar"/>
	<pathelement location="${jbossClientLib}/jboss-mdr.jar"/>
	<pathelement location="${jbossClientLib}/jboss-messaging-client.jar"/>
	<pathelement location="${jbossClientLib}/jboss-remoting.jar"/>
	<pathelement location="${jbossClientLib}/jboss-security-spi.jar"/>
	<pathelement location="${jbossClientLib}/jboss-serialization.jar"/>
	<pathelement location="${jbossClientLib}/jbosssx-client.jar"/>
	<pathelement location="${jbossClientLib}/jnp-client.jar"/>
	<pathelement location="${jbossClientLib}/log4j.jar"/>
	<pathelement location="${jbossClientLib}/trove.jar"/>
	<pathelement location="${jbossCommonLib}/hibernate-core.jar"/>
</path>

<path id="library.javahelp.classpath">
	<pathelement location="${basedir}/jars/java help/jh2.0/javahelp/lib/jh.jar"/>
</path>

<!-- Global Libraries -->

<path id="library.junit.classpath">
	<pathelement location="${basedir}/jars/junit-4.0/junit-4.0.jar"/>
</path>






<----------------------END Ant file -------------->


  was:
In an entity bean of type Request (See source) a method is defined with a switch statement. The switch statement is using enum values in the case. The Request class has annotations @Entity and @Replicable and for some object methods @Id and @GeneratedValue.

In a class called HelperClass (See source) an enum is defined. The HelperClass has annotation @Replicable.

After compile with ant script (See source) and starting JBoss with "-c all" an VerifyError occurs (See stackTrace)

Changing the switch statement into a nested if / else block makes it work.

<---------src---------->

Request.java:

package entity;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

import org.jboss.cache.pojo.annotation.Replicable;

@Entity
@Replicable
public class Request {
	
	private long id;
	private String filename;
	
	
	public Request(){
	}

	/**
	 * @return the id
	 */
	@Id
	@GeneratedValue
	public long getId() {
		return id;
	}

	/**
	 * @param id the id to set
	 */
	public void setId(long id) {
		this.id = id;
	}

	/**
	 * @return the filename
	 */
	public String getFilename() {
		return filename;
	}

	/**
	 * @param filename the filename to set
	 */
	public void setFilename(String filename) {
		this.filename = filename;
	}

	@Override
	public String toString() {
		return "id: " + id + " filename: " + filename;
	}
	
	public void inform() {
		HelperClass help = new HelperClass();
		informDeviceStateWhileHavingFullLock(help);
	}
	
	private void informDeviceStateWhileHavingFullLock(HelperClass osDeviceState) {
		switch (osDeviceState.getRuntimeStateRange()) {		
			case PROBLEM_CONNECTING: 
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case PROBLEM_SENDING:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case CONNECTED:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case INVALID:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case INTERRUPTED:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case STOPPED:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			default:
				System.out.println("Device state default is always ignored");			
				break;
		}
	}
}

HelperClass.java

package entity;

import org.jboss.cache.pojo.annotation.Replicable;
import org.jboss.cache.pojo.annotation.Transient;


@Replicable
public class HelperClass {

	private RuntimeStateRange runtimeState = RuntimeStateRange.RESTING;
	
	public static enum RuntimeStateRange {
		OFFLINE, 
		CONNECTED, 
		PROBLEM, 
		PROBLEM_CONNECTING,
		PROBLEM_SENDING,
		INTERRUPTED,
		STOPPED,
		INVALID,
		RESTING,
		BUSY,
		INITIALIZING }; 
		
	public HelperClass() {
		System.out.println("HelperClass created.");
	}

	public int EnumgetRuntimeState() {
		return runtimeState.ordinal();
	}
	
	public RuntimeStateRange getRuntimeStateRange(){
		return runtimeState;
	}
}


<--------------------------END src --------------->

<-------------------Stack trace ------------------>
15:09:15,730 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
15:09:15,730 INFO  [ServerImpl] Release ID: JBoss [The Oracle] 5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)
15:09:15,730 INFO  [ServerImpl] Bootstrap URL: null
15:09:15,730 INFO  [ServerImpl] Home Dir: C:\Java\jboss-5.1.0.GA
15:09:15,730 INFO  [ServerImpl] Home URL: file:/C:/Java/jboss-5.1.0.GA/
15:09:15,730 INFO  [ServerImpl] Library URL: file:/C:/Java/jboss-5.1.0.GA/lib/
15:09:15,730 INFO  [ServerImpl] Patch URL: null
15:09:15,730 INFO  [ServerImpl] Common Base URL: file:/C:/Java/jboss-5.1.0.GA/common/
15:09:15,746 INFO  [ServerImpl] Common Library URL: file:/C:/Java/jboss-5.1.0.GA/common/lib/
15:09:15,746 INFO  [ServerImpl] Server Name: all
15:09:15,746 INFO  [ServerImpl] Server Base Dir: C:\Java\jboss-5.1.0.GA\server
15:09:15,746 INFO  [ServerImpl] Server Base URL: file:/C:/Java/jboss-5.1.0.GA/server/
15:09:15,746 INFO  [ServerImpl] Server Config URL: file:/C:/Java/jboss-5.1.0.GA/server/all/conf/
15:09:15,746 INFO  [ServerImpl] Server Home Dir: C:\Java\jboss-5.1.0.GA\server\all
15:09:15,746 INFO  [ServerImpl] Server Home URL: file:/C:/Java/jboss-5.1.0.GA/server/all/
15:09:15,746 INFO  [ServerImpl] Server Data Dir: C:\Java\jboss-5.1.0.GA\server\all\data
15:09:15,746 INFO  [ServerImpl] Server Library URL: file:/C:/Java/jboss-5.1.0.GA/server/all/lib/
15:09:15,746 INFO  [ServerImpl] Server Log Dir: C:\Java\jboss-5.1.0.GA\server\all\log
15:09:15,746 INFO  [ServerImpl] Server Native Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp\native
15:09:15,746 INFO  [ServerImpl] Server Temp Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp
15:09:15,746 INFO  [ServerImpl] Server Temp Deploy Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp\deploy
15:09:16,355 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Java/jboss-5.1.0.GA/server/all/conf/bootstrap.xml
15:09:16,886 INFO  [VFSCacheFactory] Initializing VFSCache [org.jboss.virtual.plugins.cache.CombinedVFSCache]
15:09:16,886 INFO  [VFSCacheFactory] Using VFSCache [CombinedVFSCache[real-cache: null]]
15:09:17,152 INFO  [CopyMechanism] VFS temp dir: C:\Java\jboss-5.1.0.GA\server\all\tmp
15:09:17,152 INFO  [ZipEntryContext] VFS force nested jars copy-mode is enabled.
15:09:18,043 INFO  [ServerInfo] Java version: 1.6.0_11,Sun Microsystems Inc.
15:09:18,043 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
15:09:18,043 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 11.0-b16,Sun Microsystems Inc.
15:09:18,043 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
15:09:18,043 INFO  [ServerInfo] VM arguments: -Djboss.home=C:/Java/jboss-5.1.0.GA -Djava.library.path=C:/Program Files/Java/jdk1.6.0_11/bin -Djava.endorsed.dirs=C:/Java/jboss-5.1.0.GA/lib/endorsed -Xms256m -Xmx512m -XX:MaxPermSize=256m -Djboss.partition.name=Wernie -Dfile.encoding=Cp1252 
15:09:18,105 INFO  [JMXKernel] Legacy JMX core initialized
15:09:19,652 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 453dd5[domain=default, server=default, name=all]
15:09:21,246 INFO  [WebService] Using RMI server codebase: http://HHDEV06:8083/
15:09:26,089 INFO  [NativeServerConfig] JBoss Web Services - Stack Native Core
15:09:26,089 INFO  [NativeServerConfig] 3.1.2.GA
15:09:26,886 INFO  [AttributeCallbackItem] Owner callback not implemented.
15:09:28,495 INFO  [LogNotificationListener] Adding notification listener for logging mbean "jboss.system:service=Logging,type=Log4jService" to server org.jboss.mx.server.MBeanServerImpl at 23d278[ defaultDomain='jboss' ]
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,182 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 1507654{vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/test_clustered_slsb.jar/}
15:09:40,182 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 1507654{vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/test_clustered_slsb.jar/}
15:09:41,322 INFO  [CorbaNamingService] CORBA Naming Started
15:09:45,869 INFO  [JMXConnectorServerService] JMX Connector server: service:jmx:rmi://HHDEV06/jndi/rmi://HHDEV06:1090/jmxconnector
15:09:46,103 INFO  [MailService] Mail Service bound to java:/Mail
15:09:46,681 INFO  [SnmpAgentService] SNMP agent going active
15:09:49,166 INFO  [Wernie] Initializing partition Wernie
15:09:49,291 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2335 (cluster=Wernie)
---------------------------------------------------------
15:09:49,416 INFO  [PlatformMBeanServerRegistration] JBossCache MBeans were successfully registered to the platform mbean server.
15:09:49,447 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2335 (cluster=Wernie-HAPartitionCache)
---------------------------------------------------------
15:09:51,369 INFO  [Wernie] Number of cluster members: 1
15:09:51,384 INFO  [Wernie] Other members: 0
15:09:51,462 INFO  [RPCManagerImpl] Received new cluster view: [192.168.100.98:2335|0] [192.168.100.98:2335]
15:09:51,462 INFO  [RPCManagerImpl] Cache local address is 192.168.100.98:2335
15:09:51,462 INFO  [RPCManagerImpl] state was retrieved successfully (in 2,02 seconds)
15:09:51,478 INFO  [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA
15:09:51,478 INFO  [Wernie] Fetching serviceState (will wait for 30000 milliseconds):
15:09:51,478 INFO  [Wernie] State could not be retrieved (we are the first member in group)
15:09:51,556 INFO  [HANamingService] Started HAJNDI bootstrap; jnpPort=1100, backlog=50, bindAddress=/0.0.0.0
15:09:51,572 INFO  [DetachedHANamingService$AutomaticDiscovery] Listening on /0.0.0.0:1102, group=230.0.0.4, HA-JNDI address=192.168.100.98:1100
15:09:52,494 INFO  [UnifiedInvokerHA] Service name is jboss:service=invoker,type=unifiedha
15:09:53,040 WARN  [JBossASSecurityMetadataStore] WARNING! POTENTIAL SECURITY RISK. It has been detected that the MessageSucker component which sucks messages from one node to another has not had its password changed from the installation default. Please see the JBoss Messaging user guide for instructions on how to do this.
15:09:53,072 WARN  [AnnotationCreator] No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
15:09:53,212 WARN  [AnnotationCreator] No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
15:09:53,290 INFO  [TransactionManagerService] JBossTS Transaction Service (JTA version - tag:JBOSSTS_4_6_1_GA) - JBoss Inc.
15:09:53,290 INFO  [TransactionManagerService] Setting up property manager MBean and JMX layer
15:09:54,337 INFO  [TransactionManagerService] Initializing recovery manager
15:09:54,478 INFO  [TransactionManagerService] Recovery manager configured
15:09:54,478 INFO  [TransactionManagerService] Binding TransactionManager JNDI Reference
15:09:54,525 INFO  [TransactionManagerService] Starting transaction recovery manager
15:09:55,025 INFO  [AprLifecycleListener] The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:/Program Files/Java/jdk1.6.0_11/bin
15:09:55,087 INFO  [Http11Protocol] Initializing Coyote HTTP/1.1 on http-0.0.0.0-8080
15:09:55,087 INFO  [AjpProtocol] Initializing Coyote AJP/1.3 on ajp-0.0.0.0-8009
15:09:55,103 INFO  [StandardService] Starting service jboss.web
15:09:55,118 INFO  [StandardEngine] Starting Servlet Engine: JBoss Web/2.1.3.GA
15:09:55,181 INFO  [Catalina] Server startup in 91 ms
15:09:55,197 INFO  [TomcatDeployment] deploy, ctxPath=/juddi
15:09:55,743 INFO  [RegistryServlet] Loading jUDDI configuration.
15:09:55,743 INFO  [RegistryServlet] Resources loaded from: /WEB-INF/juddi.properties
15:09:55,743 INFO  [RegistryServlet] Initializing jUDDI components.
15:09:55,962 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
15:09:56,009 INFO  [TomcatDeployment] deploy, ctxPath=/web-console
15:09:57,462 INFO  [TomcatDeployment] deploy, ctxPath=/jbossws
15:09:57,618 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jboss-local-jdbc.rar/META-INF/ra.xml
15:09:57,634 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jboss-xa-jdbc.rar/META-INF/ra.xml
15:09:57,665 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jms-ra.rar/META-INF/ra.xml
15:09:57,696 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/mail-ra.rar/META-INF/ra.xml
15:09:57,712 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/quartz-ra.rar/META-INF/ra.xml
15:09:57,806 INFO  [SimpleThreadPool] Job execution threads will use class loader of thread: main
15:09:57,853 INFO  [QuartzScheduler] Quartz Scheduler v.1.5.2 created.
15:09:57,853 INFO  [RAMJobStore] RAMJobStore initialized.
15:09:57,853 INFO  [StdSchedulerFactory] Quartz scheduler 'DefaultQuartzScheduler' initialized from default resource file in Quartz package: 'quartz.properties'
15:09:57,853 INFO  [StdSchedulerFactory] Quartz scheduler version: 1.5.2
15:09:57,853 INFO  [QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
15:09:58,368 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
15:09:58,915 INFO  [ServerPeer] JBoss Messaging 1.4.3.GA server [0] started
15:09:59,134 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2335 (cluster=MessagingPostOffice-CTRL)
---------------------------------------------------------
15:10:01,149 INFO  [GroupMember] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 52bb2d got new view [192.168.100.98:2335|0] [192.168.100.98:2335], old view is null
15:10:01,149 INFO  [GroupMember] I am (192.168.100.98:2335)
15:10:01,149 INFO  [GroupMember] New Members : 1 ([192.168.100.98:2335])
15:10:01,149 INFO  [GroupMember] All Members : 1 ([192.168.100.98:2335])
15:10:01,181 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:7900 (cluster=MessagingPostOffice-DATA)
---------------------------------------------------------
15:10:07,227 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
15:10:07,227 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at bfd4f6 started
15:10:07,258 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
15:10:07,258 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at 1c977ef started
15:10:07,274 INFO  [QueueService] Queue[/queue/DLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:10:07,305 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
15:10:07,305 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at 14647e5 started
15:10:07,305 INFO  [QueueService] Queue[/queue/ExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:10:07,461 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'
15:10:07,883 INFO  [JBossASKernel] Created KernelDeployment for: profileservice-secured.jar
15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3
15:10:07,883 INFO  [JBossASKernel]   with dependencies:
15:10:07,883 INFO  [JBossASKernel]   and demands:
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView
15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:07,883 INFO  [JBossASKernel]   and supplies:
15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.profileservice.spi.ProfileService
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureProfileService/remote
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureProfileService/remote-org.jboss.profileservice.spi.ProfileService
15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3) to KernelDeployment of: profileservice-secured.jar
15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3
15:10:07,883 INFO  [JBossASKernel]   with dependencies:
15:10:07,883 INFO  [JBossASKernel]   and demands:
15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:07,883 INFO  [JBossASKernel]   and supplies:
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureDeploymentManager/remote-org.jboss.deployers.spi.management.deploy.DeploymentManager
15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.deployers.spi.management.deploy.DeploymentManager
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureDeploymentManager/remote
15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3) to KernelDeployment of: profileservice-secured.jar
15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3
15:10:07,883 INFO  [JBossASKernel]   with dependencies:
15:10:07,883 INFO  [JBossASKernel]   and demands:
15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:07,883 INFO  [JBossASKernel]   and supplies:
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView
15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.deployers.spi.management.ManagementView
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote
15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3) to KernelDeployment of: profileservice-secured.jar
15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at f5f77{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 1bd9f3d{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 98fc6a{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:08,024 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3
15:10:08,039 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureDeploymentManager ejbName: SecureDeploymentManager
15:10:08,102 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	SecureDeploymentManager/remote - EJB3.x Default Remote Business Interface
	SecureDeploymentManager/remote-org.jboss.deployers.spi.management.deploy.DeploymentManager - EJB3.x Remote Business Interface

15:10:08,196 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3
15:10:08,196 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureManagementView ejbName: SecureManagementView
15:10:08,211 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	SecureManagementView/remote - EJB3.x Default Remote Business Interface
	SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView - EJB3.x Remote Business Interface

15:10:08,274 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3
15:10:08,274 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureProfileServiceBean ejbName: SecureProfileService
15:10:08,305 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	SecureProfileService/remote - EJB3.x Default Remote Business Interface
	SecureProfileService/remote-org.jboss.profileservice.spi.ProfileService - EJB3.x Remote Business Interface

15:10:08,414 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3
15:10:08,414 INFO  [JBossASKernel]   with dependencies:
15:10:08,414 INFO  [JBossASKernel]   and demands:
15:10:08,414 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:08,414 INFO  [JBossASKernel]   and supplies:
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local
15:10:08,414 INFO  [JBossASKernel] 	Class:service.ITestServiceBeanManagement
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/remote
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
15:10:08,414 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3) to KernelDeployment of: test_clustered_slsb.jar
15:10:08,414 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3
15:10:08,414 INFO  [JBossASKernel]   with dependencies:
15:10:08,414 INFO  [JBossASKernel]   and demands:
15:10:08,414 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
15:10:08,414 INFO  [JBossASKernel]   and supplies:
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestClusteredBean/remote
15:10:08,414 INFO  [JBossASKernel] 	Class:session.ITestClusteredBean
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestClusteredBean/remote-session.ITestClusteredBean
15:10:08,414 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3) to KernelDeployment of: test_clustered_slsb.jar
15:10:08,414 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at ad588a{name=jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:08,602 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:08,618 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:08,649 INFO  [PlatformMBeanServerRegistration] JBossCache MBeans were successfully registered to the platform mbean server.
15:10:08,711 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2353 (cluster=Wernie-UnistreamPojoCache)
---------------------------------------------------------
15:10:10,774 INFO  [RPCManagerImpl] Received new cluster view: [192.168.100.98:2353|0] [192.168.100.98:2353]
15:10:10,774 INFO  [RPCManagerImpl] Cache local address is 192.168.100.98:2353
15:10:10,774 INFO  [RPCManagerImpl] state was retrieved successfully (in 2,11 seconds)
15:10:10,774 INFO  [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:10,930 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3,type=ManagementInterface
15:10:10,930 INFO  [JBossASKernel]   with dependencies:
15:10:10,930 INFO  [JBossASKernel]   and demands:
15:10:10,930 INFO  [JBossASKernel] 	jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3
15:10:10,930 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:10,930 INFO  [JBossASKernel]   and supplies:
15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/local
15:10:10,930 INFO  [JBossASKernel] 	Class:service.ITestServiceBeanManagement
15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/remote
15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
15:10:10,930 INFO  [JBossASKernel] Installing bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3,type=ManagementInterface) into kernel
15:10:10,961 WARN  [UniStreamCacheListener] ::::  UniStreamCacheListener created  ::::
15:10:10,961 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:10,961 INFO  [STDOUT] Create of TestServiceBean
15:10:10,961 INFO  [EJBContainer] STARTED EJB: service.TestServiceBean ejbName: TestServiceBean
15:10:10,977 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	TestServiceBean/local - EJB3.x Default Local Business Interface
	TestServiceBean/local-service.ITestServiceBeanLocal - EJB3.x Local Business Interface

15:10:11,024 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3
15:10:11,024 INFO  [EJBContainer] STARTED EJB: session.TestClusteredBean ejbName: TestClusteredBean
15:10:11,071 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	TestClusteredBean/remote - EJB3.x Default Remote Business Interface
	TestClusteredBean/remote-session.ITestClusteredBean - EJB3.x Remote Business Interface

15:10:11,102 INFO  [PersistenceUnitDeployment] Starting persistence unit persistence.unit:unitName=#unistream
15:10:11,196 INFO  [Version] Hibernate Annotations 3.4.0.GA
15:10:11,227 INFO  [Environment] Hibernate 3.3.1.GA
15:10:11,242 INFO  [Environment] hibernate.properties not found
15:10:11,242 INFO  [Environment] Bytecode provider name : javassist
15:10:11,242 INFO  [Environment] using JDK 1.4 java.sql.Timestamp handling
15:10:11,383 INFO  [Version] Hibernate Commons Annotations 3.1.0.GA
15:10:11,383 INFO  [Version] Hibernate EntityManager 3.4.0.GA
15:10:11,430 INFO  [Ejb3Configuration] Processing PersistenceUnitInfo [
	name: unistream
	...]
15:10:11,461 WARN  [Ejb3Configuration] Persistence provider caller does not implement the EJB3 spec correctly. PersistenceUnitInfo.getNewTempClassLoader() is null.
15:10:11,570 INFO  [AnnotationBinder] Binding entity from annotated class: entity.Request
15:10:11,664 INFO  [EntityBinder] Bind entity entity.Request on table Request
15:10:11,680 ERROR [AbstractKernelController] Error installing to Start: name=persistence.unit:unitName=#unistream state=Create
java.lang.VerifyError: (class: entity/Request, method: informDeviceStateWhileHavingFullLock signature: (Lentity/HelperClass;)V) Unable to pop operand off an empty stack
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
	at java.lang.Class.getDeclaredMethods(Class.java:1791)
	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredMethodProperties(JavaXClass.java:89)
	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredProperties(JavaXClass.java:106)
	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredProperties(JavaXClass.java:98)
	at org.hibernate.cfg.AnnotationBinder.addElementsOfAClass(AnnotationBinder.java:1023)
	at org.hibernate.cfg.AnnotationBinder.getElementsToProcess(AnnotationBinder.java:859)
	at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:667)
	at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:546)
	at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:291)
	at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1148)
	at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1226)
	at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:173)
	at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:854)
	at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:425)
	at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:131)
	at org.jboss.jpa.deployment.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:301)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	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.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
	at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
	at org.jboss.Main.boot(Main.java:221)
	at org.jboss.Main$1.run(Main.java:556)
	at java.lang.Thread.run(Thread.java:619)
15:10:11,774 INFO  [TomcatDeployment] deploy, ctxPath=/admin-console
15:10:11,852 INFO  [config] Initializing Mojarra (1.2_12-b01-FCS) for context '/admin-console'
15:10:15,680 INFO  [TomcatDeployment] deploy, ctxPath=/
15:10:15,726 INFO  [TomcatDeployment] deploy, ctxPath=/jmx-console
15:10:15,883 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

DEPLOYMENTS IN ERROR:
  Deployment "persistence.unit:unitName=#unistream" is in error due to the following reason(s): java.lang.VerifyError: (class: entity/Request, method: informDeviceStateWhileHavingFullLock signature: (Lentity/HelperClass;)V) Unable to pop operand off an empty stack

15:10:15,883 INFO  [Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8080
15:10:15,914 INFO  [AjpProtocol] Starting Coyote AJP/1.3 on ajp-0.0.0.0-8009
15:10:15,930 INFO  [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 1m:184ms


<----------------------END Stack trace ----------------------->





I forgot the ant file the first time. So now included the ant file and the properties file used by the build file.

> Using enum and switch with hybernate and jboss caching annotations gives an error while deploying in jboss AS5.1
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-90
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-90
>             Project: Javassist
>          Issue Type: Bug
>         Environment: JBoss 5.1.0.GA  (according to javassist manifest version 3.9.0.GA which is not in versions list) Sun JDK/JRE build 1.6.0_11-b03 Windows XP 5.1, x86
>            Reporter: Werner van Mook
>            Assignee: Shigeru Chiba
>
> In an entity bean of type Request (See source) a method is defined with a switch statement. The switch statement is using enum values in the case. The Request class has annotations @Entity and @Replicable and for some object methods @Id and @GeneratedValue.
> In a class called HelperClass (See source) an enum is defined. The HelperClass has annotation @Replicable.
> After compile with ant script (See source) and starting JBoss with "-c all" an VerifyError occurs (See stackTrace)
> Changing the switch statement into a nested if / else block makes it work.
> <---------src---------->
> Request.java:
> package entity;
> import javax.persistence.Entity;
> import javax.persistence.GeneratedValue;
> import javax.persistence.Id;
> import org.jboss.cache.pojo.annotation.Replicable;
> @Entity
> @Replicable
> public class Request {
> 	
> 	private long id;
> 	private String filename;
> 	
> 	
> 	public Request(){
> 	}
> 	/**
> 	 * @return the id
> 	 */
> 	@Id
> 	@GeneratedValue
> 	public long getId() {
> 		return id;
> 	}
> 	/**
> 	 * @param id the id to set
> 	 */
> 	public void setId(long id) {
> 		this.id = id;
> 	}
> 	/**
> 	 * @return the filename
> 	 */
> 	public String getFilename() {
> 		return filename;
> 	}
> 	/**
> 	 * @param filename the filename to set
> 	 */
> 	public void setFilename(String filename) {
> 		this.filename = filename;
> 	}
> 	@Override
> 	public String toString() {
> 		return "id: " + id + " filename: " + filename;
> 	}
> 	
> 	public void inform() {
> 		HelperClass help = new HelperClass();
> 		informDeviceStateWhileHavingFullLock(help);
> 	}
> 	
> 	private void informDeviceStateWhileHavingFullLock(HelperClass osDeviceState) {
> 		switch (osDeviceState.getRuntimeStateRange()) {		
> 			case PROBLEM_CONNECTING: 
> 				System.out.println(osDeviceState.EnumgetRuntimeState());
> 				break; 
> 			case PROBLEM_SENDING:
> 				System.out.println(osDeviceState.EnumgetRuntimeState());
> 				break; 
> 			case CONNECTED:
> 				System.out.println(osDeviceState.EnumgetRuntimeState());
> 				break; 
> 			case INVALID:
> 				System.out.println(osDeviceState.EnumgetRuntimeState());
> 				break; 
> 			case INTERRUPTED:
> 				System.out.println(osDeviceState.EnumgetRuntimeState());
> 				break; 
> 			case STOPPED:
> 				System.out.println(osDeviceState.EnumgetRuntimeState());
> 				break; 
> 			default:
> 				System.out.println("Device state default is always ignored");			
> 				break;
> 		}
> 	}
> }
> HelperClass.java
> package entity;
> import org.jboss.cache.pojo.annotation.Replicable;
> import org.jboss.cache.pojo.annotation.Transient;
> @Replicable
> public class HelperClass {
> 	private RuntimeStateRange runtimeState = RuntimeStateRange.RESTING;
> 	
> 	public static enum RuntimeStateRange {
> 		OFFLINE, 
> 		CONNECTED, 
> 		PROBLEM, 
> 		PROBLEM_CONNECTING,
> 		PROBLEM_SENDING,
> 		INTERRUPTED,
> 		STOPPED,
> 		INVALID,
> 		RESTING,
> 		BUSY,
> 		INITIALIZING }; 
> 		
> 	public HelperClass() {
> 		System.out.println("HelperClass created.");
> 	}
> 	public int EnumgetRuntimeState() {
> 		return runtimeState.ordinal();
> 	}
> 	
> 	public RuntimeStateRange getRuntimeStateRange(){
> 		return runtimeState;
> 	}
> }
> <--------------------------END src --------------->
> <-------------------Stack trace ------------------>
> 15:09:15,730 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
> 15:09:15,730 INFO  [ServerImpl] Release ID: JBoss [The Oracle] 5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)
> 15:09:15,730 INFO  [ServerImpl] Bootstrap URL: null
> 15:09:15,730 INFO  [ServerImpl] Home Dir: C:\Java\jboss-5.1.0.GA
> 15:09:15,730 INFO  [ServerImpl] Home URL: file:/C:/Java/jboss-5.1.0.GA/
> 15:09:15,730 INFO  [ServerImpl] Library URL: file:/C:/Java/jboss-5.1.0.GA/lib/
> 15:09:15,730 INFO  [ServerImpl] Patch URL: null
> 15:09:15,730 INFO  [ServerImpl] Common Base URL: file:/C:/Java/jboss-5.1.0.GA/common/
> 15:09:15,746 INFO  [ServerImpl] Common Library URL: file:/C:/Java/jboss-5.1.0.GA/common/lib/
> 15:09:15,746 INFO  [ServerImpl] Server Name: all
> 15:09:15,746 INFO  [ServerImpl] Server Base Dir: C:\Java\jboss-5.1.0.GA\server
> 15:09:15,746 INFO  [ServerImpl] Server Base URL: file:/C:/Java/jboss-5.1.0.GA/server/
> 15:09:15,746 INFO  [ServerImpl] Server Config URL: file:/C:/Java/jboss-5.1.0.GA/server/all/conf/
> 15:09:15,746 INFO  [ServerImpl] Server Home Dir: C:\Java\jboss-5.1.0.GA\server\all
> 15:09:15,746 INFO  [ServerImpl] Server Home URL: file:/C:/Java/jboss-5.1.0.GA/server/all/
> 15:09:15,746 INFO  [ServerImpl] Server Data Dir: C:\Java\jboss-5.1.0.GA\server\all\data
> 15:09:15,746 INFO  [ServerImpl] Server Library URL: file:/C:/Java/jboss-5.1.0.GA/server/all/lib/
> 15:09:15,746 INFO  [ServerImpl] Server Log Dir: C:\Java\jboss-5.1.0.GA\server\all\log
> 15:09:15,746 INFO  [ServerImpl] Server Native Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp\native
> 15:09:15,746 INFO  [ServerImpl] Server Temp Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp
> 15:09:15,746 INFO  [ServerImpl] Server Temp Deploy Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp\deploy
> 15:09:16,355 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Java/jboss-5.1.0.GA/server/all/conf/bootstrap.xml
> 15:09:16,886 INFO  [VFSCacheFactory] Initializing VFSCache [org.jboss.virtual.plugins.cache.CombinedVFSCache]
> 15:09:16,886 INFO  [VFSCacheFactory] Using VFSCache [CombinedVFSCache[real-cache: null]]
> 15:09:17,152 INFO  [CopyMechanism] VFS temp dir: C:\Java\jboss-5.1.0.GA\server\all\tmp
> 15:09:17,152 INFO  [ZipEntryContext] VFS force nested jars copy-mode is enabled.
> 15:09:18,043 INFO  [ServerInfo] Java version: 1.6.0_11,Sun Microsystems Inc.
> 15:09:18,043 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
> 15:09:18,043 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 11.0-b16,Sun Microsystems Inc.
> 15:09:18,043 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
> 15:09:18,043 INFO  [ServerInfo] VM arguments: -Djboss.home=C:/Java/jboss-5.1.0.GA -Djava.library.path=C:/Program Files/Java/jdk1.6.0_11/bin -Djava.endorsed.dirs=C:/Java/jboss-5.1.0.GA/lib/endorsed -Xms256m -Xmx512m -XX:MaxPermSize=256m -Djboss.partition.name=Wernie -Dfile.encoding=Cp1252 
> 15:09:18,105 INFO  [JMXKernel] Legacy JMX core initialized
> 15:09:19,652 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 453dd5[domain=default, server=default, name=all]
> 15:09:21,246 INFO  [WebService] Using RMI server codebase: http://HHDEV06:8083/
> 15:09:26,089 INFO  [NativeServerConfig] JBoss Web Services - Stack Native Core
> 15:09:26,089 INFO  [NativeServerConfig] 3.1.2.GA
> 15:09:26,886 INFO  [AttributeCallbackItem] Owner callback not implemented.
> 15:09:28,495 INFO  [LogNotificationListener] Adding notification listener for logging mbean "jboss.system:service=Logging,type=Log4jService" to server org.jboss.mx.server.MBeanServerImpl at 23d278[ defaultDomain='jboss' ]
> 15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
> 15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
> 15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
> 15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
> 15:09:40,182 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 1507654{vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/test_clustered_slsb.jar/}
> 15:09:40,182 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 1507654{vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/test_clustered_slsb.jar/}
> 15:09:41,322 INFO  [CorbaNamingService] CORBA Naming Started
> 15:09:45,869 INFO  [JMXConnectorServerService] JMX Connector server: service:jmx:rmi://HHDEV06/jndi/rmi://HHDEV06:1090/jmxconnector
> 15:09:46,103 INFO  [MailService] Mail Service bound to java:/Mail
> 15:09:46,681 INFO  [SnmpAgentService] SNMP agent going active
> 15:09:49,166 INFO  [Wernie] Initializing partition Wernie
> 15:09:49,291 INFO  [STDOUT] 
> ---------------------------------------------------------
> GMS: address is 192.168.100.98:2335 (cluster=Wernie)
> ---------------------------------------------------------
> 15:09:49,416 INFO  [PlatformMBeanServerRegistration] JBossCache MBeans were successfully registered to the platform mbean server.
> 15:09:49,447 INFO  [STDOUT] 
> ---------------------------------------------------------
> GMS: address is 192.168.100.98:2335 (cluster=Wernie-HAPartitionCache)
> ---------------------------------------------------------
> 15:09:51,369 INFO  [Wernie] Number of cluster members: 1
> 15:09:51,384 INFO  [Wernie] Other members: 0
> 15:09:51,462 INFO  [RPCManagerImpl] Received new cluster view: [192.168.100.98:2335|0] [192.168.100.98:2335]
> 15:09:51,462 INFO  [RPCManagerImpl] Cache local address is 192.168.100.98:2335
> 15:09:51,462 INFO  [RPCManagerImpl] state was retrieved successfully (in 2,02 seconds)
> 15:09:51,478 INFO  [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA
> 15:09:51,478 INFO  [Wernie] Fetching serviceState (will wait for 30000 milliseconds):
> 15:09:51,478 INFO  [Wernie] State could not be retrieved (we are the first member in group)
> 15:09:51,556 INFO  [HANamingService] Started HAJNDI bootstrap; jnpPort=1100, backlog=50, bindAddress=/0.0.0.0
> 15:09:51,572 INFO  [DetachedHANamingService$AutomaticDiscovery] Listening on /0.0.0.0:1102, group=230.0.0.4, HA-JNDI address=192.168.100.98:1100
> 15:09:52,494 INFO  [UnifiedInvokerHA] Service name is jboss:service=invoker,type=unifiedha
> 15:09:53,040 WARN  [JBossASSecurityMetadataStore] WARNING! POTENTIAL SECURITY RISK. It has been detected that the MessageSucker component which sucks messages from one node to another has not had its password changed from the installation default. Please see the JBoss Messaging user guide for instructions on how to do this.
> 15:09:53,072 WARN  [AnnotationCreator] No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
> 15:09:53,212 WARN  [AnnotationCreator] No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
> 15:09:53,290 INFO  [TransactionManagerService] JBossTS Transaction Service (JTA version - tag:JBOSSTS_4_6_1_GA) - JBoss Inc.
> 15:09:53,290 INFO  [TransactionManagerService] Setting up property manager MBean and JMX layer
> 15:09:54,337 INFO  [TransactionManagerService] Initializing recovery manager
> 15:09:54,478 INFO  [TransactionManagerService] Recovery manager configured
> 15:09:54,478 INFO  [TransactionManagerService] Binding TransactionManager JNDI Reference
> 15:09:54,525 INFO  [TransactionManagerService] Starting transaction recovery manager
> 15:09:55,025 INFO  [AprLifecycleListener] The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:/Program Files/Java/jdk1.6.0_11/bin
> 15:09:55,087 INFO  [Http11Protocol] Initializing Coyote HTTP/1.1 on http-0.0.0.0-8080
> 15:09:55,087 INFO  [AjpProtocol] Initializing Coyote AJP/1.3 on ajp-0.0.0.0-8009
> 15:09:55,103 INFO  [StandardService] Starting service jboss.web
> 15:09:55,118 INFO  [StandardEngine] Starting Servlet Engine: JBoss Web/2.1.3.GA
> 15:09:55,181 INFO  [Catalina] Server startup in 91 ms
> 15:09:55,197 INFO  [TomcatDeployment] deploy, ctxPath=/juddi
> 15:09:55,743 INFO  [RegistryServlet] Loading jUDDI configuration.
> 15:09:55,743 INFO  [RegistryServlet] Resources loaded from: /WEB-INF/juddi.properties
> 15:09:55,743 INFO  [RegistryServlet] Initializing jUDDI components.
> 15:09:55,962 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
> 15:09:56,009 INFO  [TomcatDeployment] deploy, ctxPath=/web-console
> 15:09:57,462 INFO  [TomcatDeployment] deploy, ctxPath=/jbossws
> 15:09:57,618 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jboss-local-jdbc.rar/META-INF/ra.xml
> 15:09:57,634 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jboss-xa-jdbc.rar/META-INF/ra.xml
> 15:09:57,665 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jms-ra.rar/META-INF/ra.xml
> 15:09:57,696 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/mail-ra.rar/META-INF/ra.xml
> 15:09:57,712 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/quartz-ra.rar/META-INF/ra.xml
> 15:09:57,806 INFO  [SimpleThreadPool] Job execution threads will use class loader of thread: main
> 15:09:57,853 INFO  [QuartzScheduler] Quartz Scheduler v.1.5.2 created.
> 15:09:57,853 INFO  [RAMJobStore] RAMJobStore initialized.
> 15:09:57,853 INFO  [StdSchedulerFactory] Quartz scheduler 'DefaultQuartzScheduler' initialized from default resource file in Quartz package: 'quartz.properties'
> 15:09:57,853 INFO  [StdSchedulerFactory] Quartz scheduler version: 1.5.2
> 15:09:57,853 INFO  [QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
> 15:09:58,368 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
> 15:09:58,915 INFO  [ServerPeer] JBoss Messaging 1.4.3.GA server [0] started
> 15:09:59,134 INFO  [STDOUT] 
> ---------------------------------------------------------
> GMS: address is 192.168.100.98:2335 (cluster=MessagingPostOffice-CTRL)
> ---------------------------------------------------------
> 15:10:01,149 INFO  [GroupMember] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 52bb2d got new view [192.168.100.98:2335|0] [192.168.100.98:2335], old view is null
> 15:10:01,149 INFO  [GroupMember] I am (192.168.100.98:2335)
> 15:10:01,149 INFO  [GroupMember] New Members : 1 ([192.168.100.98:2335])
> 15:10:01,149 INFO  [GroupMember] All Members : 1 ([192.168.100.98:2335])
> 15:10:01,181 INFO  [STDOUT] 
> ---------------------------------------------------------
> GMS: address is 192.168.100.98:7900 (cluster=MessagingPostOffice-DATA)
> ---------------------------------------------------------
> 15:10:07,227 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
> 15:10:07,227 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at bfd4f6 started
> 15:10:07,258 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
> 15:10:07,258 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at 1c977ef started
> 15:10:07,274 INFO  [QueueService] Queue[/queue/DLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
> 15:10:07,305 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
> 15:10:07,305 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at 14647e5 started
> 15:10:07,305 INFO  [QueueService] Queue[/queue/ExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
> 15:10:07,461 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'
> 15:10:07,883 INFO  [JBossASKernel] Created KernelDeployment for: profileservice-secured.jar
> 15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3
> 15:10:07,883 INFO  [JBossASKernel]   with dependencies:
> 15:10:07,883 INFO  [JBossASKernel]   and demands:
> 15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView
> 15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
> 15:10:07,883 INFO  [JBossASKernel]   and supplies:
> 15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.profileservice.spi.ProfileService
> 15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureProfileService/remote
> 15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureProfileService/remote-org.jboss.profileservice.spi.ProfileService
> 15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3) to KernelDeployment of: profileservice-secured.jar
> 15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3
> 15:10:07,883 INFO  [JBossASKernel]   with dependencies:
> 15:10:07,883 INFO  [JBossASKernel]   and demands:
> 15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
> 15:10:07,883 INFO  [JBossASKernel]   and supplies:
> 15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureDeploymentManager/remote-org.jboss.deployers.spi.management.deploy.DeploymentManager
> 15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.deployers.spi.management.deploy.DeploymentManager
> 15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureDeploymentManager/remote
> 15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3) to KernelDeployment of: profileservice-secured.jar
> 15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3
> 15:10:07,883 INFO  [JBossASKernel]   with dependencies:
> 15:10:07,883 INFO  [JBossASKernel]   and demands:
> 15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
> 15:10:07,883 INFO  [JBossASKernel]   and supplies:
> 15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView
> 15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.deployers.spi.management.ManagementView
> 15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote
> 15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3) to KernelDeployment of: profileservice-secured.jar
> 15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at f5f77{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
> 15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 1bd9f3d{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
> 15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 98fc6a{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
> 15:10:08,024 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3
> 15:10:08,039 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureDeploymentManager ejbName: SecureDeploymentManager
> 15:10:08,102 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:
> 	SecureDeploymentManager/remote - EJB3.x Default Remote Business Interface
> 	SecureDeploymentManager/remote-org.jboss.deployers.spi.management.deploy.DeploymentManager - EJB3.x Remote Business Interface
> 15:10:08,196 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3
> 15:10:08,196 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureManagementView ejbName: SecureManagementView
> 15:10:08,211 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:
> 	SecureManagementView/remote - EJB3.x Default Remote Business Interface
> 	SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView - EJB3.x Remote Business Interface
> 15:10:08,274 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3
> 15:10:08,274 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureProfileServiceBean ejbName: SecureProfileService
> 15:10:08,305 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:
> 	SecureProfileService/remote - EJB3.x Default Remote Business Interface
> 	SecureProfileService/remote-org.jboss.profileservice.spi.ProfileService - EJB3.x Remote Business Interface
> 15:10:08,414 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3
> 15:10:08,414 INFO  [JBossASKernel]   with dependencies:
> 15:10:08,414 INFO  [JBossASKernel]   and demands:
> 15:10:08,414 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
> 15:10:08,414 INFO  [JBossASKernel]   and supplies:
> 15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local
> 15:10:08,414 INFO  [JBossASKernel] 	Class:service.ITestServiceBeanManagement
> 15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/remote
> 15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
> 15:10:08,414 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3) to KernelDeployment of: test_clustered_slsb.jar
> 15:10:08,414 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3
> 15:10:08,414 INFO  [JBossASKernel]   with dependencies:
> 15:10:08,414 INFO  [JBossASKernel]   and demands:
> 15:10:08,414 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
> 15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
> 15:10:08,414 INFO  [JBossASKernel]   and supplies:
> 15:10:08,414 INFO  [JBossASKernel] 	jndi:TestClusteredBean/remote
> 15:10:08,414 INFO  [JBossASKernel] 	Class:session.ITestClusteredBean
> 15:10:08,414 INFO  [JBossASKernel] 	jndi:TestClusteredBean/remote-session.ITestClusteredBean
> 15:10:08,414 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3) to KernelDeployment of: test_clustered_slsb.jar
> 15:10:08,414 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at ad588a{name=jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
> 15:10:08,602 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
> 15:10:08,618 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
> 15:10:08,649 INFO  [PlatformMBeanServerRegistration] JBossCache MBeans were successfully registered to the platform mbean server.
> 15:10:08,711 INFO  [STDOUT] 
> ---------------------------------------------------------
> GMS: address is 192.168.100.98:2353 (cluster=Wernie-UnistreamPojoCache)
> ---------------------------------------------------------
> 15:10:10,774 INFO  [RPCManagerImpl] Received new cluster view: [192.168.100.98:2353|0] [192.168.100.98:2353]
> 15:10:10,774 INFO  [RPCManagerImpl] Cache local address is 192.168.100.98:2353
> 15:10:10,774 INFO  [RPCManagerImpl] state was retrieved successfully (in 2,11 seconds)
> 15:10:10,774 INFO  [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA
> 15:10:10,930 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3,type=ManagementInterface
> 15:10:10,930 INFO  [JBossASKernel]   with dependencies:
> 15:10:10,930 INFO  [JBossASKernel]   and demands:
> 15:10:10,930 INFO  [JBossASKernel] 	jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3
> 15:10:10,930 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
> 15:10:10,930 INFO  [JBossASKernel]   and supplies:
> 15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/local
> 15:10:10,930 INFO  [JBossASKernel] 	Class:service.ITestServiceBeanManagement
> 15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/remote
> 15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
> 15:10:10,930 INFO  [JBossASKernel] Installing bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3,type=ManagementInterface) into kernel
> 15:10:10,961 WARN  [UniStreamCacheListener] ::::  UniStreamCacheListener created  ::::
> 15:10:10,961 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
> 15:10:10,961 INFO  [STDOUT] Create of TestServiceBean
> 15:10:10,961 INFO  [EJBContainer] STARTED EJB: service.TestServiceBean ejbName: TestServiceBean
> 15:10:10,977 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:
> 	TestServiceBean/local - EJB3.x Default Local Business Interface
> 	TestServiceBean/local-service.ITestServiceBeanLocal - EJB3.x Local Business Interface
> 15:10:11,024 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3
> 15:10:11,024 INFO  [EJBContainer] STARTED EJB: session.TestClusteredBean ejbName: TestClusteredBean
> 15:10:11,071 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:
> 	TestClusteredBean/remote - EJB3.x Default Remote Business Interface
> 	TestClusteredBean/remote-session.ITestClusteredBean - EJB3.x Remote Business Interface
> 15:10:11,102 INFO  [PersistenceUnitDeployment] Starting persistence unit persistence.unit:unitName=#unistream
> 15:10:11,196 INFO  [Version] Hibernate Annotations 3.4.0.GA
> 15:10:11,227 INFO  [Environment] Hibernate 3.3.1.GA
> 15:10:11,242 INFO  [Environment] hibernate.properties not found
> 15:10:11,242 INFO  [Environment] Bytecode provider name : javassist
> 15:10:11,242 INFO  [Environment] using JDK 1.4 java.sql.Timestamp handling
> 15:10:11,383 INFO  [Version] Hibernate Commons Annotations 3.1.0.GA
> 15:10:11,383 INFO  [Version] Hibernate EntityManager 3.4.0.GA
> 15:10:11,430 INFO  [Ejb3Configuration] Processing PersistenceUnitInfo [
> 	name: unistream
> 	...]
> 15:10:11,461 WARN  [Ejb3Configuration] Persistence provider caller does not implement the EJB3 spec correctly. PersistenceUnitInfo.getNewTempClassLoader() is null.
> 15:10:11,570 INFO  [AnnotationBinder] Binding entity from annotated class: entity.Request
> 15:10:11,664 INFO  [EntityBinder] Bind entity entity.Request on table Request
> 15:10:11,680 ERROR [AbstractKernelController] Error installing to Start: name=persistence.unit:unitName=#unistream state=Create
> java.lang.VerifyError: (class: entity/Request, method: informDeviceStateWhileHavingFullLock signature: (Lentity/HelperClass;)V) Unable to pop operand off an empty stack
> 	at java.lang.Class.getDeclaredMethods0(Native Method)
> 	at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
> 	at java.lang.Class.getDeclaredMethods(Class.java:1791)
> 	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredMethodProperties(JavaXClass.java:89)
> 	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredProperties(JavaXClass.java:106)
> 	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredProperties(JavaXClass.java:98)
> 	at org.hibernate.cfg.AnnotationBinder.addElementsOfAClass(AnnotationBinder.java:1023)
> 	at org.hibernate.cfg.AnnotationBinder.getElementsToProcess(AnnotationBinder.java:859)
> 	at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:667)
> 	at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:546)
> 	at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:291)
> 	at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1148)
> 	at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1226)
> 	at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:173)
> 	at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:854)
> 	at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:425)
> 	at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:131)
> 	at org.jboss.jpa.deployment.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:301)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
> 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> 	at org.jboss.Main.boot(Main.java:221)
> 	at org.jboss.Main$1.run(Main.java:556)
> 	at java.lang.Thread.run(Thread.java:619)
> 15:10:11,774 INFO  [TomcatDeployment] deploy, ctxPath=/admin-console
> 15:10:11,852 INFO  [config] Initializing Mojarra (1.2_12-b01-FCS) for context '/admin-console'
> 15:10:15,680 INFO  [TomcatDeployment] deploy, ctxPath=/
> 15:10:15,726 INFO  [TomcatDeployment] deploy, ctxPath=/jmx-console
> 15:10:15,883 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> DEPLOYMENTS IN ERROR:
>   Deployment "persistence.unit:unitName=#unistream" is in error due to the following reason(s): java.lang.VerifyError: (class: entity/Request, method: informDeviceStateWhileHavingFullLock signature: (Lentity/HelperClass;)V) Unable to pop operand off an empty stack
> 15:10:15,883 INFO  [Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8080
> 15:10:15,914 INFO  [AjpProtocol] Starting Coyote AJP/1.3 on ajp-0.0.0.0-8009
> 15:10:15,930 INFO  [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 1m:184ms
> <----------------------END Stack trace ----------------------->
> <----------------------- Ant file ------------------------->
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <!DOCTYPE project [
> 	<!ENTITY properties SYSTEM "../../../unispool7/config/buildfiles/properties.xml">
> ]>
> <project default="deploy2Jboss" name="TestClusteredSessionBean" basedir="../..">
> 	<!-- read the properties from file -->
> 	&properties;
> 	<target name="prepare">
> 		<path id="classpath">
> 			<path refid="jboss.aop.classpath"/>
> 			<path refid="jboss.class.path"/>
> 			<pathelement path="bin"/>
> 		</path>
> 	</target>
> 	<target name="compile" depends="prepare">
> 		<delete dir="bin"/>
> 		<mkdir dir="bin"/>
> 		<javac srcdir="src" destdir="bin" deprecation="on" optimize="off" includes="**">
> 			<classpath refid="classpath"/>
> 		</javac>
> 		<copy todir="bin" filtering="no">
> 			<fileset dir="config/properties">
> 				<include name="**/*.properties"/>
> 			</fileset>
> 			<fileset dir="config">
> 				<include name="**/persistence.xml"/>
> 				<include name="**/unistream-pojo-cache-jboss-beans.xml"/>
> 			</fileset>
> 		</copy>
> 	</target>
> 	<target name="aopc" depends="compile">
> 		<unjar src="${jbossServerLib}/jbosscache-pojo.jar" dest="bin">
> 			<mapper type="flatten"/>
> 			<patternset>
>         		<include name="**/pojocache-aop.xml"/>
>     		</patternset>
> 		</unjar>
> 		<aopc compilerclasspathref="classpath" classpathref="classpath" verbose="true">
> 			<classpath path="bin"/>
> 			<src path="bin"/>
> 			<aoppath path="bin/pojocache-aop.xml"/>
> 			<aopclasspath path="bin"/>
> 		</aopc>
> 	</target>
> 	<target name="package-server-jar" depends="aopc" description="Create JAR File">
> 		<jar destfile="build/test_clustered_slsb.jar">
> 			<fileset dir="bin">
>                 <include name="**/*.*"/>
>                 <exclude name="**/Main.*"/>
>                 <exclude name="**/jndi.properties"/>
>                 <exclude name="**/pojocache-aop.xml"/>
> 			</fileset>
> 		</jar>
> 	</target>
> 	<target name="run-compile-time" depends="aopc">
> 		<java fork="yes" failOnError="true" className="Main">
> 			<sysproperty key="jboss.aop.path" value="bin/pojocache-aop.xml"/>
> 			<sysproperty key="jboss.aop.class.path" value="bin"/>
> 			<classpath refid="classpath"/>
> 		</java>
> 	</target>
> 	
> 	<target name="deploy2Jboss" depends="package-server-jar" description="Deploy the JAR File to JBoss">
> 		<copy file="build/test_clustered_slsb.jar" tofile="C:\Java\jboss-5.1.0.GA\server\all\deploy\test_clustered_slsb.jar"/>
> 	</target>
> </project>
> The properties file used by ant:
> <!-- Read in the environment variables -->
> <property environment="env"/>
> <!-- Inits the properties -->
> <tstamp/>
> <!-- needed for if, switch tasks -->
> <taskdef resource="net/sf/antcontrib/antcontrib.properties"/>
> <taskdef resource="net/sf/antcontrib/antlib.xml"/>
> <!-- base directories -->
> <property name="src" location="${basedir}/src"/>
> <property name="conf" location="${basedir}/config"/>
> <property name="build" location="${basedir}/build"/>
> <property name="dist" location="${basedir}/dist"/>
> <property name="dist-obfuscated" location="${basedir}/dist-obfuscated"/>
> <property name="ext" location="${basedir}/ext"/>
> <property name="app" value="com/hollandhouse/unistream"/>
> <!-- src directories -->
> <property name="src" location="${src}"/>
> <property name="HhLog4j" location="${src}/com/hollandhouse/unistream/framework/log/log4j/"/>
> <!-- conf directories -->
> <property name="conf-xml" location="${conf}/XML"/>
> <property name="conf-jboss" location="${conf}/JBoss"/>
> <property name="conf-properties" location="${conf}/properties"/>
> <property name="conf-properties-server" location="${conf-properties}/server"/>
> <property name="conf-properties-agent" location="${conf-properties}/agent"/>
> <property name="conf-mergefiles" location="${conf}/mergefiles"/>
> <property name="conf-buildfiles" location="${conf}/buildfiles"/>
> <property name="conf-cache" location="${conf}/cache"/>
> <!-- build directories -->
> <property name="build-generated" location="${build}/generated"/>
> <property name="generated.java.dir" value="${build-generated}"/>
> <property name="build-classes" location="${build}/classes"/>
> <property name="build-resources" location="${build}/resources"/>
> <property name="build-doc" location="${build}/doc"/>
> <property name="build-web" location="${build}/web"/>
> <!-- file names -->
> <property name="ejb-file" value="unistream-ejb3.jar"/>
> <property name="ejb-agent-file" value="unistream-agent.jar"/>
> <property name="sar-file" value="unistream.sar"/>
> <property name="sar-agent-file" value="unistream-agent.sar"/>
> <property name="entities-jar-file" value="entities.jar"/>
> <property name="jar-entities-agent-file" value="entities-agent.jar"/>
> <property name="war-file" value="unistream.war"/>
> <property name="jar-hhlog4j-file" value="hhlog4j.jar"/>
> <property name="xml-hhlog4j-file" value="log4j_unistream.xml"/>
> <property name="common-file" value="unistream-framework.jar"/>
> <property name="cli-file" value="unistream-cli.jar"/>
> <property name="ear-file" value="unistream.ear"/>
> <property name="ear-agent-file" value="unistream-agent.ear"/>
> <property name="swing-gui-file" value="unistream-swing-gui.jar"/>
> <property name="swing-gui-doc-file" value="unistream-swing-gui-doc.zip"/>
> <property name="testpage-file" value="UNISTREAM-TESTFILE"/>
> <property name="usPojoCache-file" value="unistream-pojo-cache-jboss-beans.xml"/>
> <!-- build test directories -->
> <property name="build-tests" location="${build}/tests"/>
> <property name="build-reports" location="${build}/reports"/>
> <!-- jboss settings main -->
> <property name="jbossServerProfile" value="unistream_main"/>
> <property name="jbossServer" location="${env.JBOSS_HOME}/server/${jbossServerProfile}"/>
> <property name="jbossDeploy" location="${jbossServer}/deploy"/>
> <property name="jbossServerLib" location="${jbossServer}/lib"/>
> <property name="jbossConfig" location="${jbossServer}/conf"/>
> <!-- jboss settings agent -->
> <property name="jbossAgentProfile" value="unistream_agent"/>
> <property name="jbossAgent" location="${env.JBOSS_HOME}/server/${jbossAgentProfile}"/>
> <property name="jbossAgentDeploy" location="${jbossAgent}/deploy"/>
> <property name="jbossAgentLib" location="${jbossAgent}/lib"/>
> <property name="jbossAgentConfig" location="${jbossAgent}/conf"/>
> <!-- jboss settings common -->
> <property name="jbossLib" location="${env.JBOSS_HOME}/lib"/>
> <property name="jbossClientLib" value="${env.JBOSS_HOME}/client"/>
> <property name="jbossCommonLib" location="${env.JBOSS_HOME}/common/lib"/>
> <!--        <property name="jbossDataSource" value="java:/mysqlDS"/>
> <property name="jbossDataSourceMapping" value="mySQL"/> -->
> <property name="jbossDataSource" value="java:/DefaultDS"/>
> <property name="jbossDataSourceMapping" value="Hypersonic SQL"/>
> <!-- Temp General manifest file -->
> <property name="manifest-general" location="${build}/manifest_gen.txt"/>
> <!-- Temp ClassPath manifest file -->
> <property name="manifest-classpath" location="${build}/manifest_cp.txt"/>
> <property name="version-file" value="unistream-version"/>
> <!--  jboss properties files -->
> <property name="xml-hhlog4j-path" location="${conf-properties-server}/${xml-hhlog4j-file}"/>
> <property name="xml-hhlog4j-agent-path" location="${conf-properties-agent}/${xml-hhlog4j-file}"/>
> <!-- setup the project class paths -->
> <path id="jboss.class.path">
> 	<fileset dir="${jbossLib}">
> 		<include name="*.jar"/>
> 	</fileset>
> 	<fileset dir="${env.JBOSS_HOME}/client">
> 		<include name="*.jar"/>
> 	</fileset>
> 	<fileset dir="${jbossCommonLib}">
> 		<include name="*.jar"/>
> 	</fileset>
> 	<fileset dir="${jbossServerLib}">
> 		<include name="*.jar"/>
> 	</fileset>
> </path>
> <path id="ext.class.path">
> 	<path refid="jboss.class.path"/>
> 	<fileset dir="${ext}">
> 		<include name="**/*.jar"/>
> 	</fileset>
> </path>
> <path id="jboss.aop.classpath">
> 	<fileset dir="${jbossLib}">
> 		<include name="jboss-aop.jar"/>
> 	</fileset>
> </path>
> <!-- setup the project class paths -->
> <path id="project.class.path">
> 	<path refid="ext.class.path"/>
> 	<path refid="jboss.aop.classpath"/>
> </path>
> <!-- Define the JBoss AOP compiler Ant task -->
> <taskdef name="aopc" classname="org.jboss.aop.ant.AopC" classpathref="jboss.aop.classpath"/>
> <path id="junit.test.class.path">
> 	<path refid="ext.class.path"/>
> 	<fileset dir="${dist}">
> 		<include name="*.jar"/>
> 		<include name="*.sar"/>
> 		<exclude name="*-agent.*"/>
> 	</fileset>
> 	<pathelement location="${conf-properties}"/>
> 	<pathelement location="${build-classes}"/>
> </path>
> <!-- Project Libraries -->
> <property name="gui-jar-path" value="${basedir}/unistreamgui.jar"/>
> <path id="library.gui_jars.classpath">
> 	<pathelement location="${jbossClientLib}/commons-logging.jar"/>
> 	<pathelement location="${jbossClientLib}/concurrent.jar"/>
> 	<pathelement location="${jbossClientLib}/ejb3-persistence.jar"/>
> 	<pathelement location="${jbossClientLib}/hibernate-annotations.jar"/>
> 	<pathelement location="${jbossClientLib}/javassist.jar"/>
> 	<pathelement location="${jbossClientLib}/jbossall-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-aop-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-aspect-jdk50-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-common-core.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-ejb3-common-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-ejb3-core-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-ejb3-ext-api.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-ejb3-ext-api-impl.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-ejb3-proxy-impl-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-ejb3-proxy-spi-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-ejb3-security-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-integration.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-javaee.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-logging-log4j.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-logging-spi.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-mdr.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-messaging-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-remoting.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-security-spi.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-serialization.jar"/>
> 	<pathelement location="${jbossClientLib}/jbosssx-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jnp-client.jar"/>
> 	<pathelement location="${jbossClientLib}/log4j.jar"/>
> 	<pathelement location="${jbossClientLib}/trove.jar"/>
> 	<pathelement location="${jbossCommonLib}/hibernate-core.jar"/>
> </path>
> <path id="library.javahelp.classpath">
> 	<pathelement location="${basedir}/jars/java help/jh2.0/javahelp/lib/jh.jar"/>
> </path>
> <!-- Global Libraries -->
> <path id="library.junit.classpath">
> 	<pathelement location="${basedir}/jars/junit-4.0/junit-4.0.jar"/>
> </path>
> <----------------------END Ant file -------------->

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

        

From jira-events at lists.jboss.org  Mon Jul 20 07:48:29 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Mon, 20 Jul 2009 07:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7109) Change log4j to
	2.1.15
Message-ID: <280657959.1248090509229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Change log4j to 2.1.15
----------------------

                 Key: JBAS-7109
                 URL: https://jira.jboss.org/jira/browse/JBAS-7109
             Project: JBoss Application Server
          Issue Type: Thirdparty Change
      Security Level: Public (Everyone can see)
          Components: Logging
    Affects Versions: JBossAS-5.1.0.GA
         Environment: jdk1.6u13
            Reporter: Ondrej Medek
            Assignee: David Lloyd


Apache log4j 1.2.15 is already 2 yrs released. Pls, use this version.

I like log4j 2.1.15 especially beacause of https://issues.apache.org/bugzilla/show_bug.cgi?id=32572

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

        

From jira-events at lists.jboss.org  Mon Jul 20 07:56:29 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Mon, 20 Jul 2009 07:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7109) Change log4j to
	1.2.15
In-Reply-To: <280657959.1248090509229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1341987220.1248090989404.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Medek updated JBAS-7109:
-------------------------------

        Summary: Change log4j to 1.2.15  (was: Change log4j to 2.1.15)
    Description: 
Apache log4j 1.2.15 is already 2 yrs released, but JBoss still uses 2.1.14.


I like log4j 1.2.15 especially because of https://issues.apache.org/bugzilla/show_bug.cgi?id=32572

  was:
Apache log4j 1.2.15 is already 2 yrs released, but JBoss still uses 2.1.14.


I like log4j 2.1.15 especially because of https://issues.apache.org/bugzilla/show_bug.cgi?id=32572



> Change log4j to 1.2.15
> ----------------------
>
>                 Key: JBAS-7109
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7109
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: jdk1.6u13
>            Reporter: Ondrej Medek
>            Assignee: David Lloyd
>
> Apache log4j 1.2.15 is already 2 yrs released, but JBoss still uses 2.1.14.
> I like log4j 1.2.15 especially because of https://issues.apache.org/bugzilla/show_bug.cgi?id=32572

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

        

From jira-events at lists.jboss.org  Mon Jul 20 07:56:29 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Mon, 20 Jul 2009 07:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7109) Change log4j to 1.2.15
In-Reply-To: <280657959.1248090509229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1940652042.1248090989518.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Medek closed JBAS-7109.
------------------------------

    Resolution: Duplicate Issue


This bug duplicates https://jira.jboss.org/jira/browse/JBAS-4974

> Change log4j to 1.2.15
> ----------------------
>
>                 Key: JBAS-7109
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7109
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: jdk1.6u13
>            Reporter: Ondrej Medek
>            Assignee: David Lloyd
>
> Apache log4j 1.2.15 is already 2 yrs released, but JBoss still uses 2.1.14.
> I like log4j 1.2.15 especially because of https://issues.apache.org/bugzilla/show_bug.cgi?id=32572

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

        

From jira-events at lists.jboss.org  Mon Jul 20 07:10:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 20 Jul 2009 07:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1605) management API
 needs a portable and complete serialization format
In-Reply-To: <1388356.1240496381566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2077817462.1248088229490.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1605.
------------------------------------

    Resolution: Done


fixed in the trunk

> management API needs a portable and complete serialization format
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-1605
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1605
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>         Attachments: patch-JBMESSAGING-1605.txt
>
>
> to work in a replicated environment; JBoss Messaging needs a Management API which requires complex parameter. E.g.
> public void createConnectionFactory(String name,
>                                        List<Pair<TransportConfiguration, TransportConfiguration>> connectorConfigs,
>                                        String connectionLoadBalancingPolicyClassName,
>                                        long pingPeriod,
>                                        ...);
> TransportConfiguration also contains a Map<String, Object> of parameters.
> Currently, the management code does not allow for such complex API. It only works with simple types (primitives + Strings) and String[].
> Moreover, the management API returns results (attribute values or operations results) serialized using Java serialization which won't be portable on other platforms.
> We need to define a encoding format for Management API that allow complex parameters and be portable.
> One idea'd be to use JSON[1] for that (JSON for Java is 7 classes[2] we could import in JBM source code).
> With that, the management operations would be composed of a JSON string containing:
> - the name of the resource
> - the name of the operation
> - an orderded list of the parameters (as complex as they are)
> When JBM receives a management operations, it must decode the JSON strings and find the relevant methods to call.
> There is an issue here, JSON does not contain any information on the types of parameters.
> One solution is to add the parameter type in the JSON string (e.g. this JSON object can be decoded as a TransportConfiguration class) but it add extra burden on the client sending the message and is not well suited for portability reason.
> Another solution would be to add an additional layer on the server side.
> When a management message is received, we extract the name of the resource, the operation name and the number of parameters of the operation.
> We'd have a mapper which will know based on this information what method should be called on the resource and cast the parameters from JSON to the appropriate types (e.g. Boolean, String, int but also TransportConfiguration).
> The only constraint this solution have is that there must not be 2 methods on the same resource, with the same name and the same number of parameters. The cardinality of the methods must differ to be able to identify it uniquely. If the methods have the same numbers of parameters, they must have different names (e.g. createConnectionFactoryWithDiscoveryGroup() vs. createConnectionFactory() which takes a List of Pair of TransportConfiguration)
> For return type, we could return a JSON String containing the result. This would allow for complex results (similar to CompositeData and TabularData from JMX).
> [1] http://www.json.org/
> [2] http://www.json.org/java

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

        

From jira-events at lists.jboss.org  Mon Jul 20 07:58:29 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Mon, 20 Jul 2009 07:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4974) Upgrade to log4j
 1.2.15 in JBoss5.0
In-Reply-To: <9052822.1195095618615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <615751299.1248091109382.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-4974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476840#action_12476840 ] 

Ondrej Medek commented on JBAS-4974:
------------------------------------

I would like finer SMTP configuration in 1.2.15.

> Upgrade to log4j 1.2.15 in JBoss5.0
> -----------------------------------
>
>                 Key: JBAS-4974
>                 URL: https://jira.jboss.org/jira/browse/JBAS-4974
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.0.0.Beta2
>            Reporter: cheng dan
>            Assignee: Scott M Stark
>            Priority: Minor
>
> Please upgrade to the latest stable log4j release 1.2.15 in JBoss5.0
> http://logging.apache.org/log4j/1.2/download.html

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

        

From jira-events at lists.jboss.org  Mon Jul 20 07:50:29 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Mon, 20 Jul 2009 07:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7109) Change log4j to
	2.1.15
In-Reply-To: <280657959.1248090509229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1697354141.1248090629236.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Medek updated JBAS-7109:
-------------------------------

    Description: 
Apache log4j 1.2.15 is already 2 yrs released, but JBoss still uses 2.1.14.


I like log4j 2.1.15 especially because of https://issues.apache.org/bugzilla/show_bug.cgi?id=32572

  was:
Apache log4j 1.2.15 is already 2 yrs released. Pls, use this version.

I like log4j 2.1.15 especially beacause of https://issues.apache.org/bugzilla/show_bug.cgi?id=32572

     Complexity: Low
         Labels: logging  (was: )


> Change log4j to 2.1.15
> ----------------------
>
>                 Key: JBAS-7109
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7109
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: jdk1.6u13
>            Reporter: Ondrej Medek
>            Assignee: David Lloyd
>
> Apache log4j 1.2.15 is already 2 yrs released, but JBoss still uses 2.1.14.
> I like log4j 2.1.15 especially because of https://issues.apache.org/bugzilla/show_bug.cgi?id=32572

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

        

From jira-events at lists.jboss.org  Sat Jul 18 08:58:29 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 18 Jul 2009 08:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2212) Rename Finish
 interface to Termination.
In-Reply-To: <2113079936.1247918909237.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2015793636.1247921909574.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet resolved JBRULES-2212.
---------------------------------------

    Resolution: Done


> Rename Finish interface to Termination.
> ---------------------------------------
>
>                 Key: JBRULES-2212
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2212
>             Project: JBoss Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>             Fix For: 5.1.0.M1
>
>
> Termination is more correct if you take a look at articles etc.

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

        

From jira-events at lists.jboss.org  Sat Jul 18 08:08:29 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 18 Jul 2009 08:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2212) Rename Finish
 interface to Termination.
Message-ID: <2113079936.1247918909237.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Rename Finish interface to Termination.
---------------------------------------

                 Key: JBRULES-2212
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2212
             Project: JBoss Drools
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: drools-solver
    Affects Versions: 5.0.1.FINAL
            Reporter: Geoffrey De Smet
            Assignee: Geoffrey De Smet
             Fix For: 5.1.0.M1


Termination is more correct if you take a look at articles etc.

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

        

From jira-events at lists.jboss.org  Sat Jul 18 08:25:29 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 18 Jul 2009 08:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2213) When the decider
 doesn't pick a move,
 the DefaultLocalSearchSolver shouldn't terminate by exception by try again,
 especially with relativeSelection on
Message-ID: <1398005368.1247919929317.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

When the decider doesn't pick a move, the DefaultLocalSearchSolver shouldn't terminate by exception by try again, especially with relativeSelection on
------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2213
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2213
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-solver
    Affects Versions: 5.0.1.FINAL
            Reporter: Geoffrey De Smet
            Assignee: Geoffrey De Smet
            Priority: Critical


a random bad relativeSelection could select only moves that are tabu
that no reason to stop, because the next relativeSelection could be great.

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

        

From jira-events at lists.jboss.org  Sat Jul 18 08:25:29 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 18 Jul 2009 08:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2213) When the
 decider doesn't pick a move,
 the DefaultLocalSearchSolver shouldn't terminate by exception by try again,
 especially with relativeSelection on
In-Reply-To: <1398005368.1247919929317.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <766060953.1247919929427.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476768#action_12476768 ] 

Geoffrey De Smet commented on JBRULES-2213:
-------------------------------------------

look for "TODO JBRULES-2213"

> When the decider doesn't pick a move, the DefaultLocalSearchSolver shouldn't terminate by exception by try again, especially with relativeSelection on
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2213
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2213
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Critical
>
> a random bad relativeSelection could select only moves that are tabu
> that no reason to stop, because the next relativeSelection could be great.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 06:36:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 20 Jul 2009 06:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1398126543.1248086189184.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476827#action_12476827 ] 

Howard Gao commented on JBMESSAGING-1664:
-----------------------------------------

I plan to fix this in the following way:

1. Instead of loading only non-paged messages, we load all the messages from the table. This need to change the SQL statement

LOAD_UNPAGED_REFS=SELECT MESSAGE_ID, DELIVERY_COUNT, SCHED_DELIVERY FROM JBM_MSG_REF WHERE STATE = 'C' AND CHANNEL_ID = ? AND PAGE_ORD IS NULL ORDER BY ORD

to 

LOAD_UNPAGED_REFS=SELECT MESSAGE_ID, DELIVERY_COUNT, SCHED_DELIVERY, PAGE_ORD FROM JBM_MSG_REF WHERE STATE = 'C' AND CHANNEL_ID = ? ORDER BY ORD

We add the PAGE_ORD to the selected columns as we later need this value in the code.

2. In JDBCPersistenceManager.loadFromStart() method, it checks the PAGE_ORD value while iterating through the resultset. The first batch of messages with 'null' PAGE_ORD values are real non-paged message refs, so it loads them into memory queue. When it encounters the first message ref whose PAGE_ORD is not null, it stops loading any further message refs into memory queue. When it encounters the message ref with null PAGE_ORD again, it adds them to a list and in the end update those messages with proper PAGE_ORD values.

So this way, when the JBM server is restarted, the message order will be maintained.





> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 06:40:40 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Mon, 20 Jul 2009 06:40:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6789) Allow applications
 to override logging by placing a log4j.xml inside it
In-Reply-To: <4502880.1239799773655.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2084333989.1248086440539.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476828#action_12476828 ] 

Pete Muir commented on JBAS-6789:
---------------------------------

Simply for a deployment to provide it's own logging configuration, using whatever logging configuration format/system is used by JBoss AS. (Definitely should be the same as JBoss AS, not different - I wrote log4j as that is what JBoss used until now :-)

> Allow applications to override logging by placing a log4j.xml inside it
> -----------------------------------------------------------------------
>
>                 Key: JBAS-6789
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6789
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: Pete Muir
>            Assignee: David Lloyd
>


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

        

From jira-events at lists.jboss.org  Mon Jul 20 06:40:40 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 20 Jul 2009 06:40:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1218094003.1248086440640.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476830#action_12476830 ] 

Tim Fox commented on JBMESSAGING-1664:
--------------------------------------

Err, isn't the whole point of paging, that it's not possible (not enough RAM) to load *all* the messages into memory at once?

> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 05:16:30 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Mon, 20 Jul 2009 05:16:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1674) add netty
	https support
In-Reply-To: <91041005.1246442551264.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1026060253.1248081390078.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor closed JBMESSAGING-1674.
------------------------------------

    Resolution: Done


> add netty https support
> -----------------------
>
>                 Key: JBMESSAGING-1674
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1674
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 2.0.0.beta3
>            Reporter: Andy Taylor
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>
> Netty has has support added for https when using the servlet transport. we need to make sure we support this fully and add an example. This will be available in netty 2.0.0.CR2 upwards

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

        

From jira-events at lists.jboss.org  Mon Jul 20 05:01:43 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jul 2009 05:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1014) NAKACK: SET_DIGEST
 does not overwrite the digest
Message-ID: <299603632.1248080503568.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

NAKACK: SET_DIGEST does not overwrite the digest
------------------------------------------------

                 Key: JGRP-1014
                 URL: https://jira.jboss.org/jira/browse/JGRP-1014
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.8


When we set a digest in NAKACK, we do not overwrite an element for a member if it already exists. With state transfer, the following issue can occur (see [1]):
Scenario #2:
- [NAKACK] D receives B:11 (digest is 11 now for B)
- [NAKACK] D applies the digest: this does NOT reset the digest for B to #10, but it remains #11 !!
- D delivers B:11 to the app, changes state
- D sets state, overwriting the change from B:11
--> B:11 will NOT get retransmitted as the digest in NAKACK contains it !
--> B:11 is lost

SOLUTION: maybe add a 'state' boolean to the setDigest() method and overwrite if true

This is a regression in 2.8 only; 2.6.x and 2.4.x handle SET_DIGEST correctly and do overwrite the digest.

[1] https://jira.jboss.org/jira/browse/JGRP-1013

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

        

From jira-events at lists.jboss.org  Mon Jul 20 04:54:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jul 2009 04:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1013) STATE_TRANSFER /
 STREAMING_STATE_TRANSFER: close BARRIER before applying state response
Message-ID: <1427570229.1248080069185.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

STATE_TRANSFER / STREAMING_STATE_TRANSFER: close BARRIER before applying state response
---------------------------------------------------------------------------------------

                 Key: JGRP-1013
                 URL: https://jira.jboss.org/jira/browse/JGRP-1013
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.6.11, 2.8


Current, both state transfer protocols close the barrier, process the state *request* and re-open it. However, this is NOT done for state *responses* !

The following issue could happen:
- D requests the state from A
- B multicasts #11
- D receives the digest A:5, B:10, C:44 and (in parallel) B:11

Scenario #1:
- [NAKACK] D applies the digest (is 10 for B)
- [NAKACK] D receives B:11 (is 11 now for B)
- D delivers B:11 to the app, changes state
- D sets state, overwrites the change made by B:11
--> B:11 will *not* get retransmitted as the digest in NAKACK already has it: the change made by B:11 is lost !

Scenario #2:
- [NAKACK] D receives B:11 (is 11 now for B)
- [NAKACK] D applies the digest: resets the digest for B to #10
- D sets state
- D delivers B:11 to the app, changes state
--> B:11 will get retransmitted as the digest in NAKACK doesn't contain it
--> B:11 changes state *again*: B:11 is delivered *twice* !


So scenario #1 loses B:11 while scenario #2 delivers B:11 twice, which has to be prevented.

SOLUTION: 
- Close BARRIER before state response is handled (similar to what we do with a state request)
- This way, either B:11 is handled and changes the digest in NAKACK and the app state *before* we set the digest in NAKACK and the app state, OR the digest is set in NAKACK and the app state is set from the state response and THEN B:11 is handled




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

        

From jira-events at lists.jboss.org  Mon Jul 20 03:10:53 2009
From: jira-events at lists.jboss.org (Colin Mondesir (JIRA))
Date: Mon, 20 Jul 2009 03:10:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1689) Pass
 trustStore parameters to remoting layer
Message-ID: <369523920.1248073853274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Pass trustStore parameters to remoting layer
--------------------------------------------

                 Key: JBMESSAGING-1689
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1689
             Project: JBoss Messaging
          Issue Type: Feature Request
          Components: JMS Security
    Affects Versions: 1.4.0.SP3
            Reporter: Colin Mondesir
            Assignee: Howard Gao


The two trustStore parameters:

org.jboss.remoting.trustStorePassword
org.jboss.remoting.trustStore

Are not currently passed by JBM to the remoting layer.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 03:33:41 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Mon, 20 Jul 2009 03:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
In-Reply-To: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1849770554.1248075221811.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476803#action_12476803 ] 

Lukas Krejci commented on JBAS-7108:
------------------------------------

The integration test is succeeding because there are no methods invoked on the EJBs (see the TODOs in Ejb3MetricsUnitTestCase.validateInvocationStats() method). In Jopr case we actually invoke the methods on the EJBs. The stats collection fails only then.

> Unable to collect EJB3 invocation statistics
> --------------------------------------------
>
>                 Key: JBAS-7108
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>
> When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:
> java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 02:29:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 20 Jul 2009 02:29:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1671311537.1248071369348.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476801#action_12476801 ] 

Howard Gao commented on JBMESSAGING-1664:
-----------------------------------------

The paging can disrupt the order of message delivery in the following way:

1. Starting a queue with fullSize=20, pageSize=10, downCacheSize=10
2. Sending 35 persistent messages (m0 to m34) to the queue
3. The JBM_MSG_REF table will look like this:

[code]
+------------------+----------+
| MESSAGE_ID       | PAGE_ORD |
+------------------+----------+
|    m0's id       |     NULL | 
|     ....         |     NULL | 
|    m19's id      |     NULL | 
|    m20's id      |        0 | 
|     ....         |        5 | 
|    m29's id      |        9 | 
|    m30's id      |     NULL | 
|      ....        |     NULL | 
|    m34's id      |     NULL | 
+------------------+----------+
[/code]

No the order of messages in the table is exactly the same order as they were added to the in-memory queue, only
that m20 to m34 are paged and waiting to be loaded to the in-mem queue. Please note that messages m0 to m19 have 
NULL page_ord because they are in-memory messages, messages m20 to m29 have non-null page_ord values because they
have been paged down to DB, messages m30 to m34 have NULL page_ord values because they are in the down cache and haven't 
yet been written to DB.

If we at the moment shutdown and restart the server, the messages will be loaded from the DB in the same order as before.

But if we cosume a message (m19) before shutdown, it's possible that the table may look like this

[code]
+------------------+----------+
| MESSAGE_ID       | PAGE_ORD |
+------------------+----------+
|    m0's id       |     NULL | 
|     ....         |     NULL | 
|    m18's id      |     NULL | 
|    m20's id      |        0 | 
|     ....         |        5 | 
|    m29's id      |        9 | 
|    m30's id      |     NULL | 
|      ....        |     NULL | 
|    m34's id      |     NULL | 
+------------------+----------+
[/code]

Now if we start the server again, it will load m0 to m18, plus m30 into the in-memory queue and update the paging status. The key sql statement is this

[code]
LOAD_UNPAGED_REFS=SELECT MESSAGE_ID, DELIVERY_COUNT, SCHED_DELIVERY FROM JBM_MSG_REF WHERE STATE = 'C' AND CHANNEL_ID = ? AND PAGE_ORD IS NULL ORDER BY ORD
[/code]

This will cause m30 to be delivered before messages m20 to m29. So the order is broken.


http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244557#4244557

> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 15:40:29 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 20 Jul 2009 15:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-136) JBoss STS - add
 support for batch requests
Message-ID: <1124938795.1248118829193.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss STS - add support for batch requests 
-------------------------------------------

                 Key: JBID-136
                 URL: https://jira.jboss.org/jira/browse/JBID-136
             Project: JBoss Identity
          Issue Type: Task
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha3
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: IDFED-1.0.0.alpha4


The WS-Trust specification defines the concept of batch requests in which a client can ask for multiple tokens to be issued/validated/renewed/cancelled using a single WS-Trust request. The STS must be changed so it can process such requests.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 15:44:29 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 20 Jul 2009 15:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBID-136) JBoss STS - add
 support for batch requests
In-Reply-To: <1124938795.1248118829193.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1114725905.1248119069196.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBID-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476912#action_12476912 ] 

Stefan Guilhen commented on JBID-136:
-------------------------------------

The rules for batch processing are as follows:

- if any of the requests fails, the whole request processing must fail with an exception. So, either all requests are successfully handled or an exception must be thrown.
- all the requests  in the batch must be of the same "type" (BatchIssue, BatchValidate, etc). An exception will be thrown if the request types differ.

> JBoss STS - add support for batch requests 
> -------------------------------------------
>
>                 Key: JBID-136
>                 URL: https://jira.jboss.org/jira/browse/JBID-136
>             Project: JBoss Identity
>          Issue Type: Task
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.alpha4
>
>
> The WS-Trust specification defines the concept of batch requests in which a client can ask for multiple tokens to be issued/validated/renewed/cancelled using a single WS-Trust request. The STS must be changed so it can process such requests.

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

        

From jira-events at lists.jboss.org  Fri Jul 17 13:14:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 17 Jul 2009 13:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
In-Reply-To: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <85611383.1247850869197.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476744#action_12476744 ] 

Andrew Lee Rubinger commented on JBAS-7108:
-------------------------------------------

I'll have a look and see what is causing the CCE, and more importantly, why the integration test does not reveal it.

> Unable to collect EJB3 invocation statistics
> --------------------------------------------
>
>                 Key: JBAS-7108
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>
> When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:
> java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

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

        

From jira-events at lists.jboss.org  Fri Jul 17 13:12:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 17 Jul 2009 13:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
In-Reply-To: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <486858156.1247850749274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger reassigned JBAS-7108:
-----------------------------------------

    Assignee: Andrew Lee Rubinger


> Unable to collect EJB3 invocation statistics
> --------------------------------------------
>
>                 Key: JBAS-7108
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>
> When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:
> java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

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

        

From jira-events at lists.jboss.org  Fri Jul 17 12:50:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 17 Jul 2009 12:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7107) Invocation
 statistics not collected on JMX based EJB2 managed components
In-Reply-To: <381985128.1247839649313.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1330040214.1247849429326.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476741#action_12476741 ] 

Jason T. Greene commented on JBAS-7107:
---------------------------------------

The test says they are working just fine:

http://hudson.qa.jboss.com/hudson/view/EAP-CI/job/JBoss-EAP-5.0.x-Testsuite-sun16/50/testReport/org.jboss.test.profileservice.test/JMXMappingUnitTestCase(profileservice)/testEjbMetrics/

Are you sure the test was hitting the right branch?

> Invocation statistics not collected on JMX based EJB2 managed components
> ------------------------------------------------------------------------
>
>                 Key: JBAS-7107
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7107
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>
> This was brought to light while investigating JOPR-280.
> During the Jopr AS5 plugin integration tests the metrics collection on EJB2 SFSBs, SLSBs, MDBs and Entity beans is tested.
> For session beans a single remote method is called 10 times on a single bean. The test then checks for CreateCount == 1 and for appropriate method invocation statistics.
> Both the create count and the invocation stats are always 0/empty. Note that this is also true for the MBeans of the session beans themselves when looking at the values in the jmx-console.
> For MDBs the collection statistics fails "most of the time". This might be because the JNDI name of a bean contains @object-id. Once some messages are delivered to the bean the @object-id part of the JNDI name changes from time to time. I suspect that with that change, the stats go as well.
> Entity bean metrics seem to be collected fine.

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

        

From jira-events at lists.jboss.org  Fri Jul 17 12:47:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 17 Jul 2009 12:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
In-Reply-To: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1596890511.1247849249256.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476739#action_12476739 ] 

Andrew Lee Rubinger commented on JBAS-7108:
-------------------------------------------

The integration test in JBPAPP is coming up fine.  What's the test environment leading to this exception?  I suspect a mismatch somewhere.

> Unable to collect EJB3 invocation statistics
> --------------------------------------------
>
>                 Key: JBAS-7108
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Priority: Critical
>
> When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:
> java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

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

        

From jira-events at lists.jboss.org  Fri Jul 17 11:22:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Fri, 17 Jul 2009 11:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
Message-ID: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Unable to collect EJB3 invocation statistics
--------------------------------------------

                 Key: JBAS-7108
                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.2.0.Beta1
            Reporter: Lukas Krejci
            Priority: Critical


When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:

java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)
	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)

This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

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

        

From jira-events at lists.jboss.org  Fri Jul 17 12:00:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Fri, 17 Jul 2009 12:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
In-Reply-To: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <37453870.1247846429614.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476729#action_12476729 ] 

Lukas Krejci commented on JBAS-7108:
------------------------------------

This occurs because of org.jboss.ebj3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue() method in the jboss-ejb3-metrics-deployer project.

> Unable to collect EJB3 invocation statistics
> --------------------------------------------
>
>                 Key: JBAS-7108
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Priority: Critical
>
> When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:
> java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

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

        

From jira-events at lists.jboss.org  Sun Jul 19 05:36:29 2009
From: jira-events at lists.jboss.org (Nikolay Botev (JIRA))
Date: Sun, 19 Jul 2009 05:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (HIBERNATE-112) Schema auto
 generation creates columns in alphabetical order for compound primary keys
In-Reply-To: <33331140.1237737862579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <951778208.1247996189306.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/HIBERNATE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476783#action_12476783 ] 

Nikolay Botev commented on HIBERNATE-112:
-----------------------------------------

The other bug is ANN-551, look it up here; http://opensource.atlassian.com/projects/hibernate/browse/ANN-551

> Schema auto generation creates columns in alphabetical order for compound primary keys
> --------------------------------------------------------------------------------------
>
>                 Key: HIBERNATE-112
>                 URL: https://jira.jboss.org/jira/browse/HIBERNATE-112
>             Project: Hibernate
>          Issue Type: Bug
>         Environment: JBoss AS 5.0.1 with EJB3 entities / Hibernate with MySQL Server 5.1
>            Reporter: Jochen Reinhardt
>            Assignee: Steve Ebersole
>
> Schema auto generation creates columns in alphabetical order.
> I would not mind that, but it also affects the creation of primary key indexes. These are rather useless from a database point of view, as the database will only be able to use an index for searching if the columns that are searched for are a prefix of the key. Alphabetical column order is not what one expects. Instead, I would want that my columns are sorted in the same way they appear in my annotated POJO class. I hope I am not missing some simple configuration issue...
> I have a rather complex setup with my entities and relations, using compound primary keys and references. In an entity that maps a complex m:n relationship between two entities with additional properties... Please let me know if you need more details.
> I'm using @Embedded on a primary key class and @EmbeddedId in all my entities.
> I already posted in the Hibernate forums, but I did not get an answer yet, nor did I find any information about my specific problem. The only peace of information I found so far is, that the alphabetical column sort order was introduced because of some issues related to foreign key constraints in clustered environments.  As it is already somewhat urgent, I decided to submit a bug report.
> A colleague of mine found the following in some other forum and I looked up in the source code, too - it's still there. But I do not know if it is correct in general and it only does not work for my setup.
> Cite:
> Hi all,
> I am using EJB3 with hibernate.hbm2ddl.auto=update. I notice the primary keys is been created in database in alphabetic order and not like the order defined at the embedded class. I look at the source code of Hibernate Annotations and found in AnnotationBinder class a Collections.sort at line 1024 with this comment:
> //order so that property are used in the same order when binding native query
> In my project I have primary keys with 4 or 5 fields, and many queries use only 2 ou 3 of them and are running very slow, and the cause was the wrong order of the primary keys in the database.
> I guest that sort is for fixing another bug, but is really annoying, because I need to look each primary key and adjust its order by hand.
> Is there another solution?
> Thanks in advance.

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

        

From jira-events at lists.jboss.org  Sun Jul 19 04:23:29 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 19 Jul 2009 04:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2212) Rename Finish
 interface to Termination.
In-Reply-To: <2113079936.1247918909237.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1720035088.1247991809205.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476782#action_12476782 ] 

Geoffrey De Smet commented on JBRULES-2212:
-------------------------------------------

see upgrade recipe

> Rename Finish interface to Termination.
> ---------------------------------------
>
>                 Key: JBRULES-2212
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2212
>             Project: JBoss Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>             Fix For: 5.1.0.M1
>
>
> Termination is more correct if you take a look at articles etc.

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

        

From jira-events at lists.jboss.org  Sun Jul 19 04:19:29 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 19 Jul 2009 04:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1373) Rename
 FeasibleScoreTermination to ScoreAttainedTermination
In-Reply-To: <19006052.1197046371584.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1083106601.1247991569150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated JBRULES-1373:
--------------------------------------

          Summary: Rename FeasibleScoreTermination to ScoreAttainedTermination  (was: Rename feasibleScoreFinish)
    Fix Version/s: 5.1.0.M1


> Rename FeasibleScoreTermination to ScoreAttainedTermination
> -----------------------------------------------------------
>
>                 Key: JBRULES-1373
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1373
>             Project: JBoss Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Optional
>             Fix For: 5.1.0.M1
>
>
> scoreReachedFinish might be more appropriate and less confusing with "feasible solutions"
> because a feasible solution would be able to have an unfeasible score?!?

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

        

From jira-events at lists.jboss.org  Sun Jul 19 04:21:29 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 19 Jul 2009 04:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1373) Rename
 FeasibleScoreTermination to ScoreAttainedTermination
In-Reply-To: <19006052.1197046371584.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1894430273.1247991689192.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet resolved JBRULES-1373.
---------------------------------------

    Resolution: Done


see upgrade recipe

> Rename FeasibleScoreTermination to ScoreAttainedTermination
> -----------------------------------------------------------
>
>                 Key: JBRULES-1373
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1373
>             Project: JBoss Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Optional
>             Fix For: 5.1.0.M1
>
>
> scoreReachedFinish might be more appropriate and less confusing with "feasible solutions"
> because a feasible solution would be able to have an unfeasible score?!?

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

        

From jira-events at lists.jboss.org  Fri Jul 17 10:07:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Fri, 17 Jul 2009 10:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7107) Invocation
 statistics not collected on JMX based EJB2 managed components
Message-ID: <381985128.1247839649313.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Invocation statistics not collected on JMX based EJB2 managed components
------------------------------------------------------------------------

                 Key: JBAS-7107
                 URL: https://jira.jboss.org/jira/browse/JBAS-7107
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.2.0.Beta1
            Reporter: Lukas Krejci


This was brought to light while investigating JOPR-280.

During the Jopr AS5 plugin integration tests the metrics collection on EJB2 SFSBs, SLSBs, MDBs and Entity beans is tested.

For session beans a single remote method is called 10 times on a single bean. The test then checks for CreateCount == 1 and for appropriate method invocation statistics.
Both the create count and the invocation stats are always 0/empty. Note that this is also true for the MBeans of the session beans themselves when looking at the values in the jmx-console.

For MDBs the collection statistics fails "most of the time". This might be because the JNDI name of a bean contains @object-id. Once some messages are delivered to the bean the @object-id part of the JNDI name changes from time to time. I suspect that with that change, the stats go as well.

Entity bean metrics seem to be collected fine.


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

        

From jira-events at lists.jboss.org  Mon Jul 20 16:04:29 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 20 Jul 2009 16:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-137) JBoss STS - improve
 the configuration to allow for general properties to be specified for each
 token provider
Message-ID: <333146513.1248120269086.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss STS - improve the configuration to allow for general properties to be specified for each token provider
-------------------------------------------------------------------------------------------------------------

                 Key: JBID-137
                 URL: https://jira.jboss.org/jira/browse/JBID-137
             Project: JBoss Identity
          Issue Type: Task
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha3
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: IDFED-1.0.0.alpha4


JBoss STS does not currently provide a way to specify general properties for a token provider. A token provider may be configurable (for example, a provider may take an URL of a third-party service or repository) and the configuration schema must be changed to allow the specification of properties.

The token providers should also be associated with the token element (namespace and local name) besides the token type. The reason for doing this is that validation/renewing/cancellation requests do not specify the token type explicitly so it must be inferred by the token element. The only way for the STS to figure out which provider should be used to validate the token is by having an association between token elements and providers. Something like:

<TokenProvider ProviderClass="...." TokenType="..." TokenNamespace="urn:...." TokenName="Assertion">
    <Property name="..." value="..."/>
    <Property name="..." vluae="..."/>
</TokenProvider>

A final note about configuration is about the need for the TruststoreAlias attribute of the ServiceProvider. The alias of each service provider can be configured through the ValidatingAlias element of KeyProvider, so we may just make the TruststoreAlias attribute optional.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 16:10:29 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 20 Jul 2009 16:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-138) JBoss STS - implement
 proof-of-possession token logic
Message-ID: <65021309.1248120629197.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss STS - implement proof-of-possession token logic
-----------------------------------------------------

                 Key: JBID-138
                 URL: https://jira.jboss.org/jira/browse/JBID-138
             Project: JBoss Identity
          Issue Type: Task
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha3
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: IDFED-1.0.0.alpha4


The WS-Trust specification defines the concept of a proof-of-possession token, that is, a token that can be used to verify the association between a security token and a subject. We must add support for proof tokens, both symmetric (secret key) and assymetric (certificate based). The proof must no only be included in the WS-Trust response, but also in the security tokens being generated by each token provider.

Once this has been implemented, we must change the SAML20TokenProvider so it adds the appropriate proof token to the assertion being created.

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

        

From jira-events at lists.jboss.org  Fri Jul 17 11:00:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 17 Jul 2009 11:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2211)
 StatefulKnowledgeSession leaves threads running
Message-ID: <363522950.1247842829232.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

StatefulKnowledgeSession leaves threads running
-----------------------------------------------

                 Key: JBRULES-2211
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2211
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL, 5.0.0.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1



Hi all,

 I've downloaded Drools fusion sample and started to make some changes to
the code (first of all wipe out the UI so I can test it easier).
 I tried to get to a minimal set so I can run a console main class and see
what happens but I am facing a strange behaviour.
 As soon as I start pushing events into the WorkingMemoryEntryPoint
("StockTick stream") a Thread - not daemonized since it blocks shutdown from
ending - is spawned and this prevents my JVM from shutting down (obviously
if I call System.exit(0) it will but I am avoiding this).
 I've tried both to halt and dispose the session that this entry point
belongs but with no success. Does anyone know how could I get rid of this
thread?
==================

Hi Edson!

 as I've already mentioned I've modified the sample so, if you get the StockTick sample and replace the Main class this will run fine.
 The sample shuts down fine but as I saw it sets the JFrame uses frame.setDefaultCloseOperation( WindowConstants.EXIT_ON_CLOSE ); which in turn makes the trick.

 Below the code of my modified main class:

package org.drools.examples.broker;


import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseConfiguration;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.builder.ResourceType;
import org.drools.conf.EventProcessingOption;
import org.drools.examples.broker.model.Company;
import org.drools.examples.broker.model.CompanyRegistry;
import org.drools.examples.broker.model.StockTick;
import org.drools.io.ResourceFactory;
import org.drools.runtime.StatefulKnowledgeSession;
import org.drools.runtime.rule.WorkingMemoryEntryPoint;

public class Main {
    private static final String RULES_FILE = "/broker.drl";
    static StatefulKnowledgeSession session;
    static WorkingMemoryEntryPoint tickStream;

    /**
     * @param args
     */
    public static void main(String[] args) throws Exception {
        // set up and show main window
       
        CompanyRegistry companies = new CompanyRegistry();
       
        KnowledgeBuilder builder = KnowledgeBuilderFactory.newKnowledgeBuilder();
        try {
            builder.add( ResourceFactory.newInputStreamResource( Main.class.getResourceAsStream( RULES_FILE ) ),
                         ResourceType.DRL);
        } catch ( Exception e ) {
            e.printStackTrace();
        }
        if( builder.hasErrors() ) {
            System.err.println(builder.getErrors());
            System.exit( 0 );
        }

        KnowledgeBaseConfiguration conf = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
        conf.setOption( EventProcessingOption.STREAM );
        KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase( conf );
        kbase.addKnowledgePackages( builder.getKnowledgePackages() );
       
        session = kbase.newStatefulKnowledgeSession();

        session.setGlobal( "services", new BrokerServices() {
            public void log(String message) {
                System.out.println(message);               
            }
        });

        for( Company company : companies.getCompanies() ) {
            session.insert( company );
        }
        session.fireAllRules();
       
        tickStream = session.getWorkingMemoryEntryPoint( "StockTick stream" );
 
        for (int i=10;i>0;i--) {
            tickStream.insert(new StockTick("RHT", i*10, System.currentTimeMillis()));
            session.getAgenda().getAgendaGroup( "evaluation" ).setFocus();
            session.fireAllRules();
        }
        session.dispose();
        session.halt();
        System.out.println("Still running...");
    }
   
}


regards,
Rafael Ribeiro

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

        

From jira-events at lists.jboss.org  Mon Jul 20 16:17:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 20 Jul 2009 16:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4974) Upgrade to log4j
 1.2.15 in JBoss5.0
In-Reply-To: <9052822.1195095618615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1855167105.1248121049542.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-4974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned JBAS-4974:
---------------------------------

    Assignee: David Lloyd  (was: Scott M Stark)


> Upgrade to log4j 1.2.15 in JBoss5.0
> -----------------------------------
>
>                 Key: JBAS-4974
>                 URL: https://jira.jboss.org/jira/browse/JBAS-4974
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.0.0.Beta2
>            Reporter: cheng dan
>            Assignee: David Lloyd
>            Priority: Minor
>
> Please upgrade to the latest stable log4j release 1.2.15 in JBoss5.0
> http://logging.apache.org/log4j/1.2/download.html

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

        

From jira-events at lists.jboss.org  Mon Jul 20 16:19:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 20 Jul 2009 16:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4974) Upgrade to log4j
 1.2.15 in JBoss5.0
In-Reply-To: <9052822.1195095618615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <74077697.1248121169237.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-4974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBAS-4974.
-----------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


We have updated to 1.2.15 in 6.0.  However the logging configuration uses an alternate mechanism now, so I'm not sure this will fix your problem...

> Upgrade to log4j 1.2.15 in JBoss5.0
> -----------------------------------
>
>                 Key: JBAS-4974
>                 URL: https://jira.jboss.org/jira/browse/JBAS-4974
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.0.0.Beta2
>            Reporter: cheng dan
>            Assignee: David Lloyd
>            Priority: Minor
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Please upgrade to the latest stable log4j release 1.2.15 in JBoss5.0
> http://logging.apache.org/log4j/1.2/download.html

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

        

From jira-events at lists.jboss.org  Fri Jul 17 08:42:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 17 Jul 2009 08:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1670) Disallow
 forward slashes in jms destinations
In-Reply-To: <15439568.1246092776416.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1050270959.1247834549336.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1670.
------------------------------------

    Resolution: Rejected


the destination name is never used to bind to JNDI.

In JBM 2.x, the JNDI bindings are mandatory and we will never default to the destination name to bind to JNDI.
Having forward slashes in the destination name is not an issue (see JMSServerDeployerTest)

> Disallow forward slashes in jms destinations
> --------------------------------------------
>
>                 Key: JBMESSAGING-1670
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1670
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> We need to disallow forward slashes in JMS destination names since they won't be able to be deployed in JNDI since the slash will be interperted as a subcontext by JNDI

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

        

From jira-events at lists.jboss.org  Mon Jul 20 16:22:29 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 20 Jul 2009 16:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-139) JBoss STS - implement
 token encryption logic
Message-ID: <1615009684.1248121349351.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss STS - implement token encryption logic
--------------------------------------------

                 Key: JBID-139
                 URL: https://jira.jboss.org/jira/browse/JBID-139
             Project: JBoss Identity
          Issue Type: Task
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha3
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: IDFED-1.0.0.alpha4


When the EncryptToken property is set to true, the STS must encrypt the issued token using the service provider PKC. If either the service provider or its PKC is not available (a request can be made without specifying the target service provider) we should log a warn message and leave the token unencrypted.

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

        

From jira-events at lists.jboss.org  Fri Jul 17 06:54:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Fri, 17 Jul 2009 06:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7106) Deployment Based
 On An EAR's application.xml Order No Longer Works
In-Reply-To: <1569390802.1247806049341.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1029113898.1247828069256.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476674#action_12476674 ] 

Ales Justin commented on JBAS-7106:
-----------------------------------

Previous discussion found by Alexey:
* http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4121271
* http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4127369#4127369

> Deployment Based On An EAR's application.xml Order No Longer Works
> ------------------------------------------------------------------
>
>                 Key: JBAS-7106
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7106
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>            Reporter: Jimmy Wilson
>            Assignee: Ales Justin
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-5.0.2.GA
>
>
> During deployment, even though <module-order>strict</module-order> is specified in jboss-app.xml, the EAR deployer still deploys in alphabetical order.

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

        

From jira-events at lists.jboss.org  Fri Jul 17 05:41:29 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 17 Jul 2009 05:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1688) transaction
 support in the JCA adapter isn't implemented properly
Message-ID: <92600155.1247823689314.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

transaction support in the JCA adapter isn't implemented properly
-----------------------------------------------------------------

                 Key: JBMESSAGING-1688
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1688
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0.beta3
            Reporter: Andy Taylor
            Assignee: Tim Fox
             Fix For: 2.0.0




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

        

From jira-events at lists.jboss.org  Fri Jul 17 05:45:29 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 17 Jul 2009 05:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBMESSAGING-1688) transaction
 support in the JCA adapter isn't implemented properly
Message-ID: <370770056.1247823929209.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor deleted JBMESSAGING-1688:
-------------------------------------


> transaction support in the JCA adapter isn't implemented properly
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-1688
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1688
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Andy Taylor
>            Assignee: Andy Taylor
>


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

        

From jira-events at lists.jboss.org  Fri Jul 17 05:36:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 17 Jul 2009 05:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1687) Transaction
 management/demarcation and ack modes/session creation broken in JCA RA
Message-ID: <615256574.1247823389304.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Transaction management/demarcation and ack modes/session creation broken in JCA RA
----------------------------------------------------------------------------------

                 Key: JBMESSAGING-1687
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1687
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
            Assignee: Tim Fox
            Priority: Critical
             Fix For: 2.0.0




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

        

From jira-events at lists.jboss.org  Fri Jul 17 05:43:29 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 17 Jul 2009 05:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1688) transaction
 support in the JCA adapter isn't implemented properly
In-Reply-To: <92600155.1247823689314.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1489954114.1247823809195.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor closed JBMESSAGING-1688.
------------------------------------

    Resolution: Duplicate Issue


> transaction support in the JCA adapter isn't implemented properly
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-1688
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1688
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>            Reporter: Andy Taylor
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>


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

        

From jira-events at lists.jboss.org  Fri Jul 17 05:45:29 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 17 Jul 2009 05:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1687) Transaction
 management/demarcation and ack modes/session creation broken in JCA RA
In-Reply-To: <615256574.1247823389304.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <958668194.1247823929393.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor reassigned JBMESSAGING-1687:
----------------------------------------

    Assignee: Andy Taylor  (was: Tim Fox)


> Transaction management/demarcation and ack modes/session creation broken in JCA RA
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1687
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1687
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Andy Taylor
>            Priority: Critical
>             Fix For: 2.0.0
>
>


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

        

From jira-events at lists.jboss.org  Fri Jul 17 05:41:29 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 17 Jul 2009 05:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1688) transaction
 support in the JCA adapter isn't implemented properly
In-Reply-To: <92600155.1247823689314.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1918811371.1247823689506.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor reassigned JBMESSAGING-1688:
----------------------------------------

    Assignee: Andy Taylor  (was: Tim Fox)


> transaction support in the JCA adapter isn't implemented properly
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-1688
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1688
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>            Reporter: Andy Taylor
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>


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

        

From jira-events at lists.jboss.org  Fri Jul 17 04:46:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 17 Jul 2009 04:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1012) TP: fetch physical
 address associated with logical address more quickly
Message-ID: <547183200.1247820389194.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

TP: fetch physical address associated with logical address more quickly
-----------------------------------------------------------------------

                 Key: JGRP-1012
                 URL: https://jira.jboss.org/jira/browse/JGRP-1012
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.8


Currently, when we send a unicast message and don't have the physical address available, we send a discovery request for the physical address and trash the message.

Later, when the physical address has been received and added to the transport's cache, the retransmission of the unicast message will succeed.

In order not to generate too much traffic, we send such a discovery request only every 5 seconds (hard-coded) max. However, this is for *all* addresses. So if we have physical addresses for P, Q and R missing, the total time to send the 3 discovery requests will be 15 sec max ! So we would not be able to send a unicast to R for up to 15 secs !

This is bad, we should keep track of *which* addresses we've sent out discovery requests for, and have timeouts based on individual addresses, for example in the form of a cache (keys=addrs, values=last time sent).


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

        

From jira-events at lists.jboss.org  Fri Jul 17 03:47:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 17 Jul 2009 03:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1009) Prevent merging
 during JOIN/LEAVE processing
In-Reply-To: <1137846767.1246631211429.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1738943336.1247816849131.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476659#action_12476659 ] 

Bela Ban commented on JGRP-1009:
--------------------------------

Workaround: start all instances in a cluster in staggered fashion

> Prevent merging during JOIN/LEAVE processing
> --------------------------------------------
>
>                 Key: JGRP-1009
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1009
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.9
>
>
> - Say we have V1={A,B,C} and D joins
> - A multicasts the new view V2={A,B,C,D} to {A,B,C} and sends a it via unicast to D
> - At time T1, A and C have V2, but B might still have V1
> - At timeT3 B will also have V2
> - HOWEVER, *before* T3 (at T2), A's MERGE functionality gets the current views and discovers the discrepancy
> - A will now initiate a merge. This is superfluous because B would have received V2 at T3 (maybe a few ms later) !
> This is not incorrect, but we still want to prevent spurious merges.
> SOLUTION:
> - Turn off merging during view change processing
> - This can be done via discarding of MERGE events at GMS during view processing, or by disabling merging directly in MERGE2, MERGE3, MERGEFAST. The first option looks more promising, as it requires only 1 hange in GMS

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

        

From jira-events at lists.jboss.org  Fri Jul 17 03:43:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 17 Jul 2009 03:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-974) Make 2.9 run with
	JBoss 6.x
In-Reply-To: <21960561.1241605966588.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <576794340.1247816609253.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-974:
--------------------------

    Summary: Make 2.9 run with JBoss 6.x  (was: Make 2.9 run with JBoss 5.x)


Changed to make 2.9 run with AS 6. There won't be any support for 2.9 in AS 5 !

> Make 2.9 run with JBoss 6.x
> ---------------------------
>
>                 Key: JGRP-974
>                 URL: https://jira.jboss.org/jira/browse/JGRP-974
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.9
>
>
> Currently, 2.8 does not run with JBoss 5.x because 2.8 removed some JMX classes (see below).
> java.lang.NoSuchMethodError: org.jgroups.jmx.JmxConfigurator.registerChannel(Lorg/jgroups/JChannel;Ljavax/management/MBeanServer;Ljava/lang/String;Ljava/lang/String;Z)Lorg/jgroups/jmx/JChannel;
> 	at org.jboss.ha.framework.server.JChannelFactory.registerChannel(JChannelFactory.java:1019)
> 	at org.jboss.ha.framework.server.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:279)
> 	at org.jboss.ha.framework.server.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:309)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
> 	at javax.management.StandardMBean.invoke(StandardMBean.java:391)
> 	at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.messaging.core.impl.jchannelfactory.MultiplexerChannelFactory.createControlChannel(MultiplexerChannelFactory.java:130)
> 	at org.jboss.messaging.core.impl.postoffice.GroupMember.start(GroupMember.java:116)
> 	at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.start(MessagingPostOffice.java:367)
> 	at org.jboss.messaging.core.jmx.MessagingPostOfficeService.startService(MessagingPostOfficeService.java:462)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
> 	at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:269)
> and 
> 2009-05-06 12:23:15,553 ERROR [org.jboss.mx.server.registry.BasicMBeanRegistry] (main) Cannot register MBean
> java.lang.NoClassDefFoundError: org/jgroups/jmx/JChannelFactoryMBean
> 	at java.lang.Class.getDeclaredMethods0(Native Method)
> 	at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
> 	at java.lang.Class.privateGetPublicMethods(Class.java:2547)
> 	at java.lang.Class.privateGetPublicMethods(Class.java:2557)
> 	at java.lang.Class.getMethods(Class.java:1410)
> 	at org.jboss.mx.metadata.StandardMetaData.build(StandardMetaData.java:208)
> 	at org.jboss.mx.modelmbean.XMBean.<init>(XMBean.java:224)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:202)
> 	at sun.reflect.GeneratedMethodAccessor98.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.ha.cachemanager.CacheManager.registerCache(CacheManager.java:266)
> 	at org.jboss.cache.CacheManagerImpl.getCache(CacheManagerImpl.java:124)
> 	at org.jboss.ha.cachemanager.CacheManager.getCache(CacheManager.java:244)
> 	at org.jboss.ha.framework.server.HAPartitionCacheHandlerImpl.acquireCache(HAPartitionCacheHandlerImpl.java:53)
> 	at org.jboss.ha.framework.server.ClusterPartition.startService(ClusterPartition.java:355)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
> 	at org.jboss.system.ServiceMBeanSupport.pojoStart(ServiceMBeanSupport.java:216)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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)

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

        

From jira-events at lists.jboss.org  Fri Jul 17 01:10:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 17 Jul 2009 01:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7072) Don't write a URL for
 host 0.0.0.0 in jnp-service.url
In-Reply-To: <15437469.1246547091499.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <352734757.1247807429197.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7072.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> Don't write a URL for host 0.0.0.0 in jnp-service.url
> -----------------------------------------------------
>
>                 Key: JBAS-7072
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7072
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services, Naming
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> See JOPR-254 for an explanation of the issue. This issue is to ensure NamingServiceURLWriter writes the correct URL.

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

        

From jira-events at lists.jboss.org  Fri Jul 17 00:47:29 2009
From: jira-events at lists.jboss.org (Jimmy Wilson (JIRA))
Date: Fri, 17 Jul 2009 00:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7106) Deployment Based On
 An EAR's application.xml Order No Longer Works
Message-ID: <1569390802.1247806049341.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Deployment Based On An EAR's application.xml Order No Longer Works
------------------------------------------------------------------

                 Key: JBAS-7106
                 URL: https://jira.jboss.org/jira/browse/JBAS-7106
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Deployers
    Affects Versions: JBossAS-5.1.0.GA, JBossAS-5.0.1.GA
            Reporter: Jimmy Wilson
            Assignee: Ales Justin
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-5.0.2.GA


During deployment, even though <module-order>strict</module-order> is specified in jboss-app.xml, the EAR deployer still deploys in alphabetical order.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 21:14:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 16 Jul 2009 21:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-115) Negative test for
 standard 303 validation annotation
In-Reply-To: <1562454476.1247472809212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1859957502.1247793269143.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang updated JBJCA-115:
-----------------------------

    Fix Version/s: 1.0.0.Alpha2
                       (was: 1.0.0.Alpha3)


> Negative test for standard 303 validation annotation
> ----------------------------------------------------
>
>                 Key: JBJCA-115
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-115
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> ra16standard303jbossra.rar (Invalid - must fail)
> define in ra.xml and override in jboss-ra.xml, validate should be fail

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

        

From jira-events at lists.jboss.org  Thu Jul 16 21:12:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 16 Jul 2009 21:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-119) Hibernate Validator
	4.0.0Beta1
In-Reply-To: <1098713284.1247792429189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <760415653.1247793149498.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang updated JBJCA-119:
-----------------------------

    Summary: Hibernate Validator 4.0.0Beta1  (was: Hibernate Validator 4.0.0)


> Hibernate Validator 4.0.0Beta1
> ------------------------------
>
>                 Key: JBJCA-119
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-119
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> for 303 requirement 

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

        

From jira-events at lists.jboss.org  Thu Jul 16 20:46:29 2009
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 16 Jul 2009 20:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2210) Move
 getSessionClock from WorkingMemory to Runtime.
Message-ID: <1308806284.1247791589350.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Move getSessionClock from WorkingMemory to Runtime.
---------------------------------------------------

                 Key: JBRULES-2210
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2210
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-api
            Reporter: Mark Proctor
            Assignee: Mark Proctor




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

        

From jira-events at lists.jboss.org  Thu Jul 16 20:42:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 20:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <720064499.1247791349125.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476642#action_12476642 ] 

Richard Achmatowicz commented on JGRP-1011:
-------------------------------------------

Test results: I list the test which failed repeatedly, followed by the tests which failed, but passed on retry, organized by IP version.

ipv4:
repeatable failure:
* CloseTest(tcp).testMultipleConnectsAndDisconnects (also fails on 2.6.10.GA - no regression)
* FlushCloseOpenTest(tcp).testAndLoop (also fails on 2.6.10.GA - no regression)
passed on retry:
* none

ipv4.local:
repeatable failure:
* CloseTest(tcp).testMultipleConnectsAndDisconnects (also fails on 2.6.10.GA - no regression)
* FlushCloseOpenTest(tcp).testAndLoop (also fails on 2.6.10.GA - no regression)
passed on retry:
* SharedTransportTest(udp).testSendingOfMessageAfterChannelClose
* ConnectStressTest (timeout)

ipv6:
repeatable failure:
* CloseTest(tcp).testMultipleConnectsAndDisconnects (not testsed on 2.6.10.GA)
* FlushCloseOpenTest(tcp).testAndLoop (not tested on 2.6.10.GA)
passed on retry:
* MergeTest(udp).testMerging4Members

ipv6.local:
repeatable failure:
* CloseTest(tcp).testMultipleConnectsAndDisconnects (not testsed on 2.6.10.GA)
* FlushCloseOpenTest(tcp).testAndLoop (not tested on 2.6.10.GA)
* MergeTest(udp).testMerging4Members/testMerge4Members (this test is really broken for IPv6 as it uses IPv4 default mcast addresses and needs to be recrafted) 
passed on retry:
* ConnectStressTest (timeout)






> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 20:44:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 20:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <405592524.1247791469180.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1011:
--------------------------------------

    Attachment: JGroups_2_6_11_GA_reports.zip


The full set of automated test results.


> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>         Attachments: JGroups_2_6_11_GA_reports.zip
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 21:00:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 16 Jul 2009 21:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-119) Hibernate Validator
	4.0.0
Message-ID: <1098713284.1247792429189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Hibernate Validator 4.0.0
-------------------------

                 Key: JBJCA-119
                 URL: https://jira.jboss.org/jira/browse/JBJCA-119
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha2


for 303 requirement 

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

        

From jira-events at lists.jboss.org  Thu Jul 16 19:07:29 2009
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Thu, 16 Jul 2009 19:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7079) Can't redirect root
 requests without ROOT.war
In-Reply-To: <1964202660.1246909311435.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1097048145.1247785649167.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Remy Maucherat resolved JBAS-7079.
----------------------------------

    Resolution: Won't Fix


Yes, the request must be mappable to a webapp for any processing to occur. This behavior has existed in Tomcat for a long time now, and is a feature request (that is not really doable, though).

> Can't redirect root requests without ROOT.war
> ---------------------------------------------
>
>                 Key: JBAS-7079
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7079
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows XP, JDK 1.6.0_14
>            Reporter: Rostyslav Smirnov
>            Assignee: Remy Maucherat
>
> When ROOT.war is removed, root URL request always returns 404, ignoring URL rewrite rules.
> Steps to reproduce:
> 1) Set up a single URL rewriting rule for jboss.web engine that redirects root requests:
> RewriteRule ^/$ /admin-console/ [R]
> At this point everything works and http://localhost:8080/ becomes http://localhost:8080/admin-console/
> 2) As the ROOT.war is now inaccessible, remove or rename it. Now http://localhost:8080/ just returns 404, ignoring the rule.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 17:39:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 16 Jul 2009 17:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBID-135) Release
 JBossIdentity 1.0.0.alpha4 consolidated stack
In-Reply-To: <1636549018.1247764829150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1093282804.1247780369842.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBID-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476632#action_12476632 ] 

Anil Saldhana commented on JBID-135:
------------------------------------

OpenID Integration: http://www.jboss.org/community/wiki/OpenIDIntegrationinJBossIdentity

> Release JBossIdentity 1.0.0.alpha4 consolidated stack
> -----------------------------------------------------
>
>                 Key: JBID-135
>                 URL: https://jira.jboss.org/jira/browse/JBID-135
>             Project: JBoss Identity
>          Issue Type: Release
>          Components: Community-Build
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDENTITY-1.0.0.alpha4
>
>


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

        

From jira-events at lists.jboss.org  Thu Jul 16 16:58:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 16 Jul 2009 16:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-535) Move task
 configuration in server-config.xml into a target
Message-ID: <1701874410.1247777909261.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Move task configuration in server-config.xml into a target
----------------------------------------------------------

                 Key: JBBUILD-535
                 URL: https://jira.jboss.org/jira/browse/JBBUILD-535
             Project: JBoss Build System
          Issue Type: Sub-task
            Reporter: Paul Gier




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

        

From jira-events at lists.jboss.org  Thu Jul 16 16:58:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 16 Jul 2009 16:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-535) Move task
 configuration in server-config.xml into a target
In-Reply-To: <1701874410.1247777909261.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <312303994.1247777909316.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-535:
------------------------------

    Description: Currently the task definitions in server-config.xml are not inside a target.  This means that they can't depend on another target to define their path references.  This should be changed so that everything is done inside targets.


> Move task configuration in server-config.xml into a target
> ----------------------------------------------------------
>
>                 Key: JBBUILD-535
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-535
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>
> Currently the task definitions in server-config.xml are not inside a target.  This means that they can't depend on another target to define their path references.  This should be changed so that everything is done inside targets.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 14:43:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Thu, 16 Jul 2009 14:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7050)
 "ClassNotFoundException:
 org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote
 calls to ManagementView.getTemplate()
Message-ID: <925585302.1247769809297.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukas Krejci resolved JBAS-7050.
--------------------------------

    Resolution: Done


It is possible to create both the data sources and connection factories remotely from JON now.

> "ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote calls to ManagementView.getTemplate()
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7050
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7050
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Lukas Krejci
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to create a datasource in AS5 using JON, the following exception occurs:
> java.lang.ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo                                                                                               
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)                                                                                            
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)                                                                                                 
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)                                                                                                                         
>         at java.lang.Class.forName0(Native Method)                                                                                                                                               
>         at java.lang.Class.forName(Class.java:247)                                                                                                                                               
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)                                                                   
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)                                                                                                               
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)                                                                                                                  
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)                                                                                                  
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)                                                                                                               
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)                                                                                                              
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)                                                                                                                 
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)                                                        
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)                                                                  
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)                                                                              
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)                                                                                     
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)                                                                        
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)                                                                             
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)                                                                                                 
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                                    
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                                     
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                            
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                          
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                        
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)                                                                                                                
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)                                                             
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> I was only able to find this class in jboss-embedded-all maven module.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 13:34:40 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 16 Jul 2009 13:34:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-118) SJC/RADeployer:
 Merge specification and vendor metadata
Message-ID: <369789920.1247765680901.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC/RADeployer: Merge specification and vendor metadata
-------------------------------------------------------

                 Key: JBJCA-118
                 URL: https://jira.jboss.org/jira/browse/JBJCA-118
             Project: JBoss JCA
          Issue Type: Task
          Components: Deployer
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Merge the metadata from the specification (ConnectorMetaData) with our metadata (JBossRAMetaData).

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

        

From jira-events at lists.jboss.org  Thu Jul 16 13:20:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 16 Jul 2009 13:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-135) Release JBossIdentity
 1.0.0.alpha4 consolidated stack
Message-ID: <1636549018.1247764829150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Release JBossIdentity 1.0.0.alpha4 consolidated stack
-----------------------------------------------------

                 Key: JBID-135
                 URL: https://jira.jboss.org/jira/browse/JBID-135
             Project: JBoss Identity
          Issue Type: Release
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana




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

        

From jira-events at lists.jboss.org  Thu Jul 16 13:30:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 16 Jul 2009 13:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-135) Release JBossIdentity
 1.0.0.alpha4 consolidated stack
In-Reply-To: <1636549018.1247764829150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <33191448.1247765429372.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-135.
------------------------------

    Resolution: Done


> Release JBossIdentity 1.0.0.alpha4 consolidated stack
> -----------------------------------------------------
>
>                 Key: JBID-135
>                 URL: https://jira.jboss.org/jira/browse/JBID-135
>             Project: JBoss Identity
>          Issue Type: Release
>          Components: Community-Build
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDENTITY-1.0.0.alpha4
>
>


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

        

From jira-events at lists.jboss.org  Thu Jul 16 13:32:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 16 Jul 2009 13:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-101) SJC/RADeployer:
	Annotations
In-Reply-To: <387057390.1246458111738.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1930491883.1247765549507.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-101.
-----------------------------------

    Resolution: Done


> SJC/RADeployer: Annotations
> ---------------------------
>
>                 Key: JBJCA-101
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-101
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Handle annotations in the resource adapter to build a complete metadata model for the adapter.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 13:22:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 16 Jul 2009 13:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-135) Release JBossIdentity
 1.0.0.alpha4 consolidated stack
In-Reply-To: <1636549018.1247764829150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1263951989.1247764949320.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-135:
-------------------------------

    Component/s: Community-Build


> Release JBossIdentity 1.0.0.alpha4 consolidated stack
> -----------------------------------------------------
>
>                 Key: JBID-135
>                 URL: https://jira.jboss.org/jira/browse/JBID-135
>             Project: JBoss Identity
>          Issue Type: Release
>          Components: Community-Build
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDENTITY-1.0.0.alpha4
>
>


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

        

From jira-events at lists.jboss.org  Thu Jul 16 13:22:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 16 Jul 2009 13:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-135) Release JBossIdentity
 1.0.0.alpha4 consolidated stack
In-Reply-To: <1636549018.1247764829150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <707962810.1247764949216.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-135:
-------------------------------

    Fix Version/s: IDENTITY-1.0.0.alpha4


> Release JBossIdentity 1.0.0.alpha4 consolidated stack
> -----------------------------------------------------
>
>                 Key: JBID-135
>                 URL: https://jira.jboss.org/jira/browse/JBID-135
>             Project: JBoss Identity
>          Issue Type: Release
>          Components: Community-Build
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDENTITY-1.0.0.alpha4
>
>


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

        

From jira-events at lists.jboss.org  Thu Jul 16 13:32:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 16 Jul 2009 13:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-102) SJC/RADeployer:
 Merge annotations and metadata
In-Reply-To: <2016998490.1246458231392.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1576339021.1247765549633.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-102:
----------------------------------

    Summary: SJC/RADeployer: Merge annotations and metadata  (was: SJC/RADeployer: Merge metadata)


> SJC/RADeployer: Merge annotations and metadata
> ----------------------------------------------
>
>                 Key: JBJCA-102
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-102
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Merge the metadata from the XML and the annotations into a single model.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 13:20:29 2009
From: jira-events at lists.jboss.org (Tihomir Surdilovic (JIRA))
Date: Thu, 16 Jul 2009 13:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2060) change package
 format in drools-ant-tests from .dpkg to .pkg
In-Reply-To: <6008222.1239823702637.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <828410585.1247764829333.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tihomir Surdilovic updated JBRULES-2060:
----------------------------------------

    Fix Version/s: 5.1.0.M1
                       (was: 5.0.2)


> change package format in drools-ant-tests from .dpkg to .pkg
> ------------------------------------------------------------
>
>                 Key: JBRULES-2060
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2060
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-ant
>            Reporter: Tihomir Surdilovic
>            Assignee: Tihomir Surdilovic
>             Fix For: 5.1.0.M1
>
>
> drools-ant-tests example build file for binformat="package" creates .dpkg extension. This should follow the "standard" .pkg extension. 

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

        

From jira-events at lists.jboss.org  Thu Jul 16 13:32:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Thu, 16 Jul 2009 13:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7074) some jars required
 by remote Profile Service clients are not included in client/ or
 client/jbossall-client.jar's Manifest classpath
In-Reply-To: <631441563.1246562451433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2072459338.1247765549417.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7074:
-------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=154819


> some jars required by remote Profile Service clients are not included in client/ or client/jbossall-client.jar's Manifest classpath
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7074
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7074
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The following jar is missing from client/jbossall-client.jar's Manifest classpath and from client/:
>    common/lib/jboss-security-aspects.jar
> Its corresponding Maven artifact is org.jboss.aspects:jboss-security-aspects.
> If I find any others, I will update this JIRA.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 12:06:41 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 16 Jul 2009 12:06:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-134) Release JBoss
 Identity Federation Stack 1.0.0.alpha4
Message-ID: <732256241.1247760401619.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Release JBoss Identity Federation Stack 1.0.0.alpha4
----------------------------------------------------

                 Key: JBID-134
                 URL: https://jira.jboss.org/jira/browse/JBID-134
             Project: JBoss Identity
          Issue Type: Release
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana


With the OpenID integration.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 12:38:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 16 Jul 2009 12:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-134) Release JBoss Identity
 Federation Stack 1.0.0.alpha4
In-Reply-To: <732256241.1247760401619.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1668205321.1247762309341.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-134.
------------------------------

    Resolution: Done


> Release JBoss Identity Federation Stack 1.0.0.alpha4
> ----------------------------------------------------
>
>                 Key: JBID-134
>                 URL: https://jira.jboss.org/jira/browse/JBID-134
>             Project: JBoss Identity
>          Issue Type: Release
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> With the OpenID integration.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 12:10:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 16 Jul 2009 12:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-134) Release JBoss
 Identity Federation Stack 1.0.0.alpha4
In-Reply-To: <732256241.1247760401619.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <825978082.1247760629135.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-134:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha4


> Release JBoss Identity Federation Stack 1.0.0.alpha4
> ----------------------------------------------------
>
>                 Key: JBID-134
>                 URL: https://jira.jboss.org/jira/browse/JBID-134
>             Project: JBoss Identity
>          Issue Type: Release
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> With the OpenID integration.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 12:22:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 12:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <379195124.1247761349138.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476583#action_12476583 ] 

Richard Achmatowicz commented on JGRP-1011:
-------------------------------------------

The issue JGRP-956 has now been cleared up and was the result of an incorrect setting for java.net.preferIPv4Stack. See the JIRA issue for more details.

The updates to the issue also confirm that:
(i) binding to multicast sockets is possible in IPv6
(ii) when we do bind to miulticast, the crosstalk problem does not appear as in IPv4



> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 12:51:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 12:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-956) Binding to mcast
 address in UDP.java is not working on Linux with IPv6
In-Reply-To: <3739279.1239718822407.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <544345652.1247763089249.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz closed JGRP-956.
------------------------------------

    Fix Version/s: 2.4.7
                   2.6.11
       Resolution: Done


Changed error message in 2.6.11 - need to change for Branch 2.4 and Branch 2.8


> Binding to mcast address in UDP.java is not working on Linux with IPv6
> ----------------------------------------------------------------------
>
>                 Key: JGRP-956
>                 URL: https://jira.jboss.org/jira/browse/JGRP-956
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> On Linux and Solaris platforms, when setting up the main multicast receiver socket, Bela allows binding the socket to its multicast address, like this:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> SocketAddress group_sock_addr = new InetSocketAddress(group_addr, port) ;
> MulticastSocket s = new MulticastSocket(group_sock_addr) ;    // funny
> s.joinGroup(group_addr) ;
> Binding to the multicast address on Linux and Solaris was done in order to avoid the promiscuous traffic problem. A detailed discussion on the matter can be found in the bugzilla report:https://bugzilla.redhat.com/show_bug.cgi?id=231899. 
> This works on Linux with IPv4 but is not working on Linux with IPv6 for the multicast-address ff02::1 - an error message is being generated (SocketException, invalid argument) and  the code then tries to create the same multicast address in the usual way:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> MulticastSocket s = new MulticastSocket(port) ;
> s.setInterface(bind_addr) ;
> s.joinGroup(group_addr) ;
> This is only a problem in that it generates a confusing error message about using mixed IPv4 / IPv6 stacks, but the socket continues to work correctly as far as I can tell.
> Haven't confirmed this, but I believe the promiscuous traffic issue does not arise with IPv6 multicast sockets.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 13:05:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 13:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <244359301.1247763929407.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476596#action_12476596 ] 

Richard Achmatowicz commented on JGRP-1011:
-------------------------------------------

There is still a problem when using scoped link-local IPv6 addresses, related to JDK issues. E.g. for addresses such as 

fe80::215:58ff:fec8:81a8%eth0

we get failures (messages are not delivered correctly), and this varies by JDK. So for this release, i'm not going to address these issues. 

Some of the problems were described in: https://jira.jboss.org/jira/browse/JGRP-976


> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 12:49:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 12:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-956) Binding to mcast
 address in UDP.java is not working on Linux with IPv6
In-Reply-To: <3739279.1239718822407.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <450807553.1247762969368.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476592#action_12476592 ] 

Richard Achmatowicz commented on JGRP-956:
------------------------------------------

On Brian's suggestion, changed to:

16:35:20,231 WARN [UDP] could not bind to /ff02:0:0:0:0:1:2:3 (IPv6 address); make sure your mcast_addr is of the same type as the preferred IP stack (IPv4 or IPv6), by checking the value of the system properties java.net.preferIPv4Stack and java.net.preferIPv6Addresses. Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details). Exception was: java.net.SocketException: Invalid argument


> Binding to mcast address in UDP.java is not working on Linux with IPv6
> ----------------------------------------------------------------------
>
>                 Key: JGRP-956
>                 URL: https://jira.jboss.org/jira/browse/JGRP-956
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> On Linux and Solaris platforms, when setting up the main multicast receiver socket, Bela allows binding the socket to its multicast address, like this:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> SocketAddress group_sock_addr = new InetSocketAddress(group_addr, port) ;
> MulticastSocket s = new MulticastSocket(group_sock_addr) ;    // funny
> s.joinGroup(group_addr) ;
> Binding to the multicast address on Linux and Solaris was done in order to avoid the promiscuous traffic problem. A detailed discussion on the matter can be found in the bugzilla report:https://bugzilla.redhat.com/show_bug.cgi?id=231899. 
> This works on Linux with IPv4 but is not working on Linux with IPv6 for the multicast-address ff02::1 - an error message is being generated (SocketException, invalid argument) and  the code then tries to create the same multicast address in the usual way:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> MulticastSocket s = new MulticastSocket(port) ;
> s.setInterface(bind_addr) ;
> s.joinGroup(group_addr) ;
> This is only a problem in that it generates a confusing error message about using mixed IPv4 / IPv6 stacks, but the socket continues to work correctly as far as I can tell.
> Haven't confirmed this, but I believe the promiscuous traffic issue does not arise with IPv6 multicast sockets.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 12:16:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 12:16:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-956) Binding to mcast
 address in UDP.java is not working on Linux with IPv6
In-Reply-To: <3739279.1239718822407.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1969186399.1247760989562.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476582#action_12476582 ] 

Richard Achmatowicz commented on JGRP-956:
------------------------------------------

May want to change the error message to:

16:35:20,231 WARN [UDP] could not bind to /ff02:0:0:0:0:1:2:3 (IPv6 address); make sure your mcast_addr is of the same type as the IP stack (IPv4 or IPv6), by checking the value of the system property java.net.preferIPv4Stack. Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details).
Exception was: java.net.SocketException: Invalid argument


> Binding to mcast address in UDP.java is not working on Linux with IPv6
> ----------------------------------------------------------------------
>
>                 Key: JGRP-956
>                 URL: https://jira.jboss.org/jira/browse/JGRP-956
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> On Linux and Solaris platforms, when setting up the main multicast receiver socket, Bela allows binding the socket to its multicast address, like this:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> SocketAddress group_sock_addr = new InetSocketAddress(group_addr, port) ;
> MulticastSocket s = new MulticastSocket(group_sock_addr) ;    // funny
> s.joinGroup(group_addr) ;
> Binding to the multicast address on Linux and Solaris was done in order to avoid the promiscuous traffic problem. A detailed discussion on the matter can be found in the bugzilla report:https://bugzilla.redhat.com/show_bug.cgi?id=231899. 
> This works on Linux with IPv4 but is not working on Linux with IPv6 for the multicast-address ff02::1 - an error message is being generated (SocketException, invalid argument) and  the code then tries to create the same multicast address in the usual way:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> MulticastSocket s = new MulticastSocket(port) ;
> s.setInterface(bind_addr) ;
> s.joinGroup(group_addr) ;
> This is only a problem in that it generates a confusing error message about using mixed IPv4 / IPv6 stacks, but the socket continues to work correctly as far as I can tell.
> Haven't confirmed this, but I believe the promiscuous traffic issue does not arise with IPv6 multicast sockets.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 12:16:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 12:16:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-956) Binding to mcast
 address in UDP.java is not working on Linux with IPv6
In-Reply-To: <3739279.1239718822407.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1569845658.1247760989418.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476580#action_12476580 ] 

Richard Achmatowicz commented on JGRP-956:
------------------------------------------

The confusing error message which is generated when we try to bind to IPv6 multicast address is:
16:35:19,970 INFO [DefaultPartition] Initializing partition DefaultPartition
16:35:20,231 WARN [UDP] could not bind to /ff02:0:0:0:0:1:2:3 (IPv6 address); make sure your mcast_addr is of the same type as the IP stack (IPv4 or IPv6).
Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details).
Exception was: java.net.SocketException: Invalid argument
16:35:20,289 INFO [STDOUT]
---------------------------------------------------------
GMS: address is fe80:0:0:0:215:17ff:fe2d:6821:44270 (cluster=DefaultPartition)
---------------------------------------------------------

It turns out that this message is confusing, but entirely accurate. This exception occurs when three conditions are present:
(i) we pass an IPv6 multicast address
(ii) we try to bind to the multicast socket formed from multicast address and multicast port
(iii) we prefer the IPv4 stack using java.net.preferIPv4Stack=true

After the exception
java.net.SocketException: Invalid argument               (i.e. you're trying to bind an IPv6 mcast address to an IPv4 stack)
the code will then try to bind only to the multicast port and it is indeed the case that when we bind to the multicast port only in IPv6, we do get crosstalk.


> Binding to mcast address in UDP.java is not working on Linux with IPv6
> ----------------------------------------------------------------------
>
>                 Key: JGRP-956
>                 URL: https://jira.jboss.org/jira/browse/JGRP-956
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> On Linux and Solaris platforms, when setting up the main multicast receiver socket, Bela allows binding the socket to its multicast address, like this:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> SocketAddress group_sock_addr = new InetSocketAddress(group_addr, port) ;
> MulticastSocket s = new MulticastSocket(group_sock_addr) ;    // funny
> s.joinGroup(group_addr) ;
> Binding to the multicast address on Linux and Solaris was done in order to avoid the promiscuous traffic problem. A detailed discussion on the matter can be found in the bugzilla report:https://bugzilla.redhat.com/show_bug.cgi?id=231899. 
> This works on Linux with IPv4 but is not working on Linux with IPv6 for the multicast-address ff02::1 - an error message is being generated (SocketException, invalid argument) and  the code then tries to create the same multicast address in the usual way:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> MulticastSocket s = new MulticastSocket(port) ;
> s.setInterface(bind_addr) ;
> s.joinGroup(group_addr) ;
> This is only a problem in that it generates a confusing error message about using mixed IPv4 / IPv6 stacks, but the socket continues to work correctly as far as I can tell.
> Haven't confirmed this, but I believe the promiscuous traffic issue does not arise with IPv6 multicast sockets.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 12:32:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 12:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <403032961.1247761949113.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476587#action_12476587 ] 

Richard Achmatowicz commented on JGRP-1011:
-------------------------------------------

Testing for the release usually involves the following set of tests:
(i) run the unit/functional tests (unittests-xml)
(ii) run the non-unit tests against udp (all-tests-udp)
(iii) run the non-unit tests against tcp (all-tests-tcp)
(iv) run the manual tests

These tests are usually run against IPv4 non-loopback addresses.
However, this time, I will run the tests against 
a) IPv4 loopback addresses 
b) IPv4 non-loopback addresses
c) IPv6 loopback addresses 
d) IPv6 non-loopback, global addresses

The configs used are as follows:

// IPv4 loopback
jgroups.bind_addr=127.0.0.1
jgroups.tcpping.initial_hosts=127.0.0.1[7800]
jgroups.udp.mcast_addr=232.15.15.15
jgroups.udp.mcast_port=45588
jgroups.udp.ip_ttl=5
jgroups.tunnel.router_host=127.0.0.1
jgroups.tunnel.router_port=12001
# use true for IPv6 and false for IPv4 
jgroups.useIPv6=false

// IPv4 non-loopback
jgroups.bind_addr=192.168.2.12
jgroups.tcpping.initial_hosts=192.168.2.12[7800]
jgroups.udp.mcast_addr=232.15.15.15
jgroups.udp.mcast_port=45588
jgroups.udp.ip_ttl=5
jgroups.tunnel.router_host=192.168.2.12
jgroups.tunnel.router_port=12001
# use true for IPv6 and false for IPv4 
jgroups.useIPv6=false

// IPv6 loopback
jgroups.bind_addr=::1
jgroups.tcpping.initial_hosts=::1[7800]
jgroups.udp.mcast_addr=ff01::1
jgroups.udp.mcast_port=45588
jgroups.udp.ip_ttl=5
jgroups.tunnel.router_host=::1
jgroups.tunnel.router_port=12001
# use true for IPv6 and false for IPv4 
jgroups.useIPv6=true

// IPv6 non-loopback
jgroups.bind_addr=3ffe:ffff:0100:f101::1
jgroups.tcpping.initial_hosts=3ffe:ffff:0100:f101::1[7800]
jgroups.udp.mcast_addr=ff0e::1:2:3
jgroups.udp.mcast_port=45588
jgroups.udp.ip_ttl=5
jgroups.tunnel.router_host=3ffe:ffff:0100:f101::1
jgroups.tunnel.router_port=12001
# use true for IPv6 and false for IPv4 
jgroups.useIPv6=true



> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 12:06:41 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 16 Jul 2009 12:06:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1605) management
 API needs a portable and complete serialization format
In-Reply-To: <1388356.1240496381566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1717522063.1247760401568.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned JBMESSAGING-1605:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> management API needs a portable and complete serialization format
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-1605
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1605
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>         Attachments: patch-JBMESSAGING-1605.txt
>
>
> to work in a replicated environment; JBoss Messaging needs a Management API which requires complex parameter. E.g.
> public void createConnectionFactory(String name,
>                                        List<Pair<TransportConfiguration, TransportConfiguration>> connectorConfigs,
>                                        String connectionLoadBalancingPolicyClassName,
>                                        long pingPeriod,
>                                        ...);
> TransportConfiguration also contains a Map<String, Object> of parameters.
> Currently, the management code does not allow for such complex API. It only works with simple types (primitives + Strings) and String[].
> Moreover, the management API returns results (attribute values or operations results) serialized using Java serialization which won't be portable on other platforms.
> We need to define a encoding format for Management API that allow complex parameters and be portable.
> One idea'd be to use JSON[1] for that (JSON for Java is 7 classes[2] we could import in JBM source code).
> With that, the management operations would be composed of a JSON string containing:
> - the name of the resource
> - the name of the operation
> - an orderded list of the parameters (as complex as they are)
> When JBM receives a management operations, it must decode the JSON strings and find the relevant methods to call.
> There is an issue here, JSON does not contain any information on the types of parameters.
> One solution is to add the parameter type in the JSON string (e.g. this JSON object can be decoded as a TransportConfiguration class) but it add extra burden on the client sending the message and is not well suited for portability reason.
> Another solution would be to add an additional layer on the server side.
> When a management message is received, we extract the name of the resource, the operation name and the number of parameters of the operation.
> We'd have a mapper which will know based on this information what method should be called on the resource and cast the parameters from JSON to the appropriate types (e.g. Boolean, String, int but also TransportConfiguration).
> The only constraint this solution have is that there must not be 2 methods on the same resource, with the same name and the same number of parameters. The cardinality of the methods must differ to be able to identify it uniquely. If the methods have the same numbers of parameters, they must have different names (e.g. createConnectionFactoryWithDiscoveryGroup() vs. createConnectionFactory() which takes a List of Pair of TransportConfiguration)
> For return type, we could return a JSON String containing the result. This would allow for complex results (similar to CompositeData and TabularData from JMX).
> [1] http://www.json.org/
> [2] http://www.json.org/java

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

        

From jira-events at lists.jboss.org  Thu Jul 16 12:14:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 12:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-956) Binding to mcast
 address in UDP.java is not working on Linux with IPv6
In-Reply-To: <3739279.1239718822407.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1937328907.1247760869330.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476578#action_12476578 ] 

Richard Achmatowicz commented on JGRP-956:
------------------------------------------

Well, it turns out that it is possible to bind to IPv6 multicast addresses, that it does not lead to crosstalk when we do so, and that this jira issue was the result of incorrect coding of the Java system property java.net.preferIPv6Stack.

I modified Brian's promiscuous.jar so that it took an additional boolean parameter: true -> bind to multicast socket; false -> bind to multicast port only.

So, in the case of IPv4 addresses, we can bind to port only:
$ java -jar promiscuoustraffic.jar 192.168.2.12 192.168.2.12 230.10.11.12 230.10.11.13 64000 1 false
setting up sender socket with address /192.168.2.12
setting up good receiver socket with address /230.10.11.12
binding mcast socket to port:64000
setting up bad receiver socket with address /230.10.11.13
binding mcast socket to port:64000
Listening on address /230.10.11.12
Listening on address /230.10.11.13
Sending 'Hello' on /230.10.11.12:64000
/230.10.11.13:64000 -- Received Hello
/230.10.11.12:64000 -- Received Hello
Bad news. Detected the Promiscuous Traffic problem. Received Hello on undesired address /230.10.11.13

Or we can bind to multicast address:
$ java -Djava.net.preferIPv4Stack=true -jar promiscuoustraffic.jar 192.168.2.12 192.168.2.12 230.10.11.12 230.10.11.13 64000 1 true
setting up sender socket with address /192.168.2.12
setting up good receiver socket with address /230.10.11.12
binding mcast socket to address:/230.10.11.12:64000
setting up bad receiver socket with address /230.10.11.13
binding mcast socket to address:/230.10.11.13:64000
Listening on address /230.10.11.12
Listening on address /230.10.11.13
Sending 'Hello' on /230.10.11.12:64000
/230.10.11.12:64000 -- Received Hello
Good news. Did not detect the Promiscuous Traffic problem.


We can now show that promiscuous traffic does not occur when binding to multicast address on Fedora 8 with JDK 5:

$ java -jar promiscuoustraffic.jar 3ffe:ffff:100:f101::1 3ffe:ffff:100:f101::1 ff0e::1:2:2 ff0e::1:2:3 64000 1 true
setting up sender socket with address /3ffe:ffff:100:f101:0:0:0:1
setting up good receiver socket with address /ff0e:0:0:0:0:1:2:2
binding mcast socket to address:/ff0e:0:0:0:0:1:2:2:64000
setting up bad receiver socket with address /ff0e:0:0:0:0:1:2:3
binding mcast socket to address:/ff0e:0:0:0:0:1:2:3:64000
Listening on address /ff0e:0:0:0:0:1:2:2
Listening on address /ff0e:0:0:0:0:1:2:3
Sending 'Hello' on /ff0e:0:0:0:0:1:2:2:64000
/ff0e:0:0:0:0:1:2:2:64000 -- Received Hello
Good news. Did not detect the Promiscuous Traffic problem.

and that if we prefer the IPv4 stack with an IPv6 mcast address, we get the exception above:

$ java -Djava.net.preferIPv4Stack=true -jar promiscuoustraffic.jar 3ffe:ffff:100:f101::1 3ffe:ffff:100:f101::1 ff0e::1:2:3 ff0e::1:2:4 64000 0
setting up sender socket with address /3ffe:ffff:100:f101:0:0:0:1
setting up good receiver socket with address /ff0e:0:0:0:0:1:2:3
binding mcast socket to port:64000
java.net.SocketException: Invalid argument
        at java.net.PlainDatagramSocketImpl.join(Native Method)
        at java.net.PlainDatagramSocketImpl.join(PlainDatagramSocketImpl.java:172)
        at java.net.MulticastSocket.joinGroup(MulticastSocket.java:276)
        at org.jboss.test.cluster.test.PromiscuousTrafficTester$MulticastReceiver.<init>(PromiscuousTrafficTester.java:222)
        at org.jboss.test.cluster.test.PromiscuousTrafficTester.setUpSockets(PromiscuousTrafficTester.java:144)
        at org.jboss.test.cluster.test.PromiscuousTrafficTester.<init>(PromiscuousTrafficTester.java:67)
        at org.jboss.test.cluster.test.PromiscuousTrafficTester.main(PromiscuousTrafficTester.java:191)

Promiscuous traffic does occur if we bind to multicast port only:
$ java -jar promiscuoustraffic.jar 3ffe:ffff:100:f101::1 3ffe:ffff:100:f101::1 ff0e::1:2:3 ff0e::1:2:4 64000 0setting up sender socket with address /3ffe:ffff:100:f101:0:0:0:1
setting up good receiver socket with address /ff0e:0:0:0:0:1:2:3
binding mcast socket to port:64000
setting up bad receiver socket with address /ff0e:0:0:0:0:1:2:4
binding mcast socket to port:64000
Listening on address /ff0e:0:0:0:0:1:2:3
Listening on address /ff0e:0:0:0:0:1:2:4
Sending 'Hello' on /ff0e:0:0:0:0:1:2:3:64000
/ff0e:0:0:0:0:1:2:4:64000 -- Received Hello
/ff0e:0:0:0:0:1:2:3:64000 -- Received Hello
Bad news. Detected the Promiscuous Traffic problem. Received Hello on undesired address /ff0e:0:0:0:0:1:2:4


> Binding to mcast address in UDP.java is not working on Linux with IPv6
> ----------------------------------------------------------------------
>
>                 Key: JGRP-956
>                 URL: https://jira.jboss.org/jira/browse/JGRP-956
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> On Linux and Solaris platforms, when setting up the main multicast receiver socket, Bela allows binding the socket to its multicast address, like this:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> SocketAddress group_sock_addr = new InetSocketAddress(group_addr, port) ;
> MulticastSocket s = new MulticastSocket(group_sock_addr) ;    // funny
> s.joinGroup(group_addr) ;
> Binding to the multicast address on Linux and Solaris was done in order to avoid the promiscuous traffic problem. A detailed discussion on the matter can be found in the bugzilla report:https://bugzilla.redhat.com/show_bug.cgi?id=231899. 
> This works on Linux with IPv4 but is not working on Linux with IPv6 for the multicast-address ff02::1 - an error message is being generated (SocketException, invalid argument) and  the code then tries to create the same multicast address in the usual way:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> MulticastSocket s = new MulticastSocket(port) ;
> s.setInterface(bind_addr) ;
> s.joinGroup(group_addr) ;
> This is only a problem in that it generates a confusing error message about using mixed IPv4 / IPv6 stacks, but the socket continues to work correctly as far as I can tell.
> Haven't confirmed this, but I believe the promiscuous traffic issue does not arise with IPv6 multicast sockets.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 16:30:29 2009
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Mon, 20 Jul 2009 16:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7110)
 ClusterPartition.ThreadGate can block shutdown of AS
Message-ID: <1909704028.1248121829865.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

ClusterPartition.ThreadGate can block shutdown of AS
----------------------------------------------------

                 Key: JBAS-7110
                 URL: https://jira.jboss.org/jira/browse/JBAS-7110
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


The following stack trace appears in a thread dump, after a failure to shutdown the AS within the testsuite:

Thread: JBoss Shutdown Hook : priority:5, demon:true, threadId:11, threadState:TIMED_WAITING
- waiting on <0x1d7ada9> (a org.jboss.ha.framework.server.ClusterPartition$ThreadGate)
java.lang.Object.wait(Native Method)
org.jboss.ha.framework.server.ClusterPartition$ThreadGate.await(ClusterPartition.java:2381)
org.jboss.ha.framework.server.ClusterPartition.callAsynchMethodOnCluster(ClusterPartition.java:1325)
org.jboss.ha.framework.server.DistributedReplicantManagerImpl.remove(DistributedReplicantManagerImpl.java:448)
org.jboss.profileservice.cluster.repository.DefaultRepositoryClusteringHandler.shutdown(DefaultRepositoryClusteringHandler.java:275)
org.jboss.system.server.profileservice.repository.clustered.ClusteredDeploymentRepository.unload(ClusteredDeploymentRepository.java:459)
org.jboss.system.server.profile.repository.AbstractProfile.destroy(AbstractProfile.java:163)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:97)
org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:77)
org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.uninstall(AbstractProfileLifeCycleAction.java:57)
org.jboss.system.server.profileservice.repository.AbstractProfileAction.uninstall(AbstractProfileAction.java:70)
org.jboss.system.server.profileservice.repository.AbstractProfileService.uninstall(AbstractProfileService.java:417)
org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1665)
org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1276)
org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1180)
org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1235)
org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1180)
org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1235)
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:828)
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
org.jboss.system.server.profileservice.repository.AbstractProfileService.deactivateProfile(AbstractProfileService.java:448)
org.jboss.system.server.profileservice.ProfileServiceBootstrap.deactivateProfiles(ProfileServiceBootstrap.java:381)
org.jboss.system.server.profileservice.ProfileServiceBootstrap.shutdown(ProfileServiceBootstrap.java:339)
org.jboss.bootstrap.AbstractServerImpl.shutdownServer(AbstractServerImpl.java:571)
org.jboss.bootstrap.AbstractServerImpl$ShutdownHook.run(AbstractServerImpl.java:909)

The root cause is a bug in ThreadGate.await(long), which does not correctly return if the timeout value is reached while the gate is still closed.

This same issue was found and fixed in JBC.  See JBCACHE-1173.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 11:46:29 2009
From: jira-events at lists.jboss.org (Tihomir Surdilovic (JIRA))
Date: Thu, 16 Jul 2009 11:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2060) change package
 format in drools-ant-tests from .dpkg to .pkg
In-Reply-To: <6008222.1239823702637.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <380215583.1247759189213.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tihomir Surdilovic resolved JBRULES-2060.
-----------------------------------------

    Fix Version/s: 5.0.2
       Resolution: Done


resolved

> change package format in drools-ant-tests from .dpkg to .pkg
> ------------------------------------------------------------
>
>                 Key: JBRULES-2060
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2060
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-ant
>            Reporter: Tihomir Surdilovic
>            Assignee: Tihomir Surdilovic
>             Fix For: 5.0.2
>
>
> drools-ant-tests example build file for binformat="package" creates .dpkg extension. This should follow the "standard" .pkg extension. 

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

        

From jira-events at lists.jboss.org  Thu Jul 16 12:00:29 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 16 Jul 2009 12:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7104) Typo in windows
 run.bat prevents inclusion of tools.jar
In-Reply-To: <261786877.1247752482824.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <533233057.1247760029312.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved JBAS-7104.
--------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1
       Resolution: Done


Typo is fixed in Branch_5_x + trunk.  

> Typo in windows run.bat prevents inclusion of tools.jar
> -------------------------------------------------------
>
>                 Key: JBAS-7104
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7104
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Kevin Conner
>            Assignee: Scott Marlow
>            Priority: Trivial
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Just noticed the following in the windows run.bat while investigating an issue.
>   if "x%JAVAC_JAR%" == "x" (
>     set "RUNJAR=%JAVAC_JAR%;%JBOSS_HOME%\bin\run.jar"
>   ) else (
>     set "RUNJAR=%JBOSS_HOME%\bin\run.jar"
>   )
> The set commands should be reversed.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 11:31:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 16 Jul 2009 11:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1686) Add more
 transactional options for the JCA adapter
Message-ID: <301051903.1247758289359.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add more transactional options for the JCA adapter
--------------------------------------------------

                 Key: JBMESSAGING-1686
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1686
             Project: JBoss Messaging
          Issue Type: Feature Request
            Reporter: Clebert Suconic
            Assignee: Clebert Suconic
             Fix For: 2.0.0


It should be possible to configure transactions for MDBs in a better fashion. Like receiving messages non-transactionally, or batching a number of transactions, even if this would mean non-compliant but activated by the user's choice.



We already have:
- Local Transaction
- XA Transaction


The options I'm thinking:
We should add:


- Batching transactions (commit on every X records... like most users do when processing a high number of messages outside the application server)
- NonTransactional (messages being received non transactionally.. what should be good for Non Persistent Messages)


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

        

From jira-events at lists.jboss.org  Thu Jul 16 11:50:29 2009
From: jira-events at lists.jboss.org (Kevin Conner (JIRA))
Date: Thu, 16 Jul 2009 11:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7104) Typo in windows
 run.bat prevents inclusion of tools.jar
In-Reply-To: <261786877.1247752482824.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <502917765.1247759429845.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476573#action_12476573 ] 

Kevin Conner commented on JBAS-7104:
------------------------------------

We embed wise within the ESB (SOA platform) and this requires the compiler to compile WS proxies.  Not an ideal situation but one we need for now.

> Typo in windows run.bat prevents inclusion of tools.jar
> -------------------------------------------------------
>
>                 Key: JBAS-7104
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7104
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Kevin Conner
>            Assignee: Scott Marlow
>            Priority: Trivial
>
> Just noticed the following in the windows run.bat while investigating an issue.
>   if "x%JAVAC_JAR%" == "x" (
>     set "RUNJAR=%JAVAC_JAR%;%JBOSS_HOME%\bin\run.jar"
>   ) else (
>     set "RUNJAR=%JBOSS_HOME%\bin\run.jar"
>   )
> The set commands should be reversed.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 11:11:43 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 16 Jul 2009 11:11:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7104) Typo in windows
 run.bat prevents inclusion of tools.jar
In-Reply-To: <261786877.1247752482824.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1712398080.1247757103209.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476567#action_12476567 ] 

Scott Marlow commented on JBAS-7104:
------------------------------------

Yes, this is clearly a typo.  What is the impact of not having the Java compiler on the system classpath when starting the as?  Is this impacting Tomcat jsp compiling?  I'm just curious what the issue was.

> Typo in windows run.bat prevents inclusion of tools.jar
> -------------------------------------------------------
>
>                 Key: JBAS-7104
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7104
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Kevin Conner
>            Assignee: Scott Marlow
>            Priority: Trivial
>
> Just noticed the following in the windows run.bat while investigating an issue.
>   if "x%JAVAC_JAR%" == "x" (
>     set "RUNJAR=%JAVAC_JAR%;%JBOSS_HOME%\bin\run.jar"
>   ) else (
>     set "RUNJAR=%JBOSS_HOME%\bin\run.jar"
>   )
> The set commands should be reversed.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 10:49:40 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 16 Jul 2009 10:49:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1670) Disallow
 forward slashes in jms destinations
In-Reply-To: <15439568.1246092776416.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <633708526.1247755780980.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned JBMESSAGING-1670:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> Disallow forward slashes in jms destinations
> --------------------------------------------
>
>                 Key: JBMESSAGING-1670
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1670
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> We need to disallow forward slashes in JMS destination names since they won't be able to be deployed in JNDI since the slash will be interperted as a subcontext by JNDI

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

        

From jira-events at lists.jboss.org  Thu Jul 16 10:16:42 2009
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Thu, 16 Jul 2009 10:16:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2433) Portlet
 Instance creation problem, when new portlet is deployed
In-Reply-To: <1003923183.1247753369204.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <127693052.1247753802882.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476561#action_12476561 ] 

Prabhat Jha commented on JBPORTAL-2433:
---------------------------------------

Hi Vijay,

Did you search and discuss this in portal user forum? If so, please comment with forum URL. Otherwise, please start a thread in forum. It's not a good idea to create a jira issue for every problem right away without first verifying if it's a bug or limitation of product

> Portlet Instance creation problem, when new portlet is deployed 
> ----------------------------------------------------------------
>
>                 Key: JBPORTAL-2433
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2433
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.7.0 Final
>         Environment: Tested in Windows and Linux OS
>            Reporter: vijay chaudhry
>             Fix For: 2.7.0 Final
>
>
> Take the scenario, I have created a portlet DemoPortlet with instance name DemoPortletInstance.
> Now I decided to undeploy the DemoPortlet.war file and Again I created one more Portlet with name TestPortlet and here I created the Instance name as DemoPortletInstance. Which is same as above portlet which I already undeployed.
> Now what is there on the admin screen. Portlet definition is created correctly but Portlet Instance is not displayed under Portlet Instances tab under Admin tab. Now If I try to create the instance name DemoPortletInstance manually then it is not creating that instance and in logs it says that instance already exists.
> But I cann't use that instance in the application.
> I think it is bug.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 10:51:29 2009
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 16 Jul 2009 10:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7104) Typo in windows
 run.bat prevents inclusion of tools.jar
In-Reply-To: <261786877.1247752482824.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <835489940.1247755889190.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dimitris Andreadis reassigned JBAS-7104:
----------------------------------------

    Assignee: Scott Marlow


> Typo in windows run.bat prevents inclusion of tools.jar
> -------------------------------------------------------
>
>                 Key: JBAS-7104
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7104
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Kevin Conner
>            Assignee: Scott Marlow
>            Priority: Trivial
>
> Just noticed the following in the windows run.bat while investigating an issue.
>   if "x%JAVAC_JAR%" == "x" (
>     set "RUNJAR=%JAVAC_JAR%;%JBOSS_HOME%\bin\run.jar"
>   ) else (
>     set "RUNJAR=%JBOSS_HOME%\bin\run.jar"
>   )
> The set commands should be reversed.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 10:09:29 2009
From: jira-events at lists.jboss.org (vijay chaudhry (JIRA))
Date: Thu, 16 Jul 2009 10:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2433) Portlet Instance
 creation problem, when new portlet is deployed
Message-ID: <1003923183.1247753369204.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Portlet Instance creation problem, when new portlet is deployed 
----------------------------------------------------------------

                 Key: JBPORTAL-2433
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2433
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Portlet
    Affects Versions: 2.7.0 Final
         Environment: Tested in Windows and Linux OS
            Reporter: vijay chaudhry
             Fix For: 2.7.0 Final



Take the scenario, I have created a portlet DemoPortlet with instance name DemoPortletInstance.
Now I decided to undeploy the DemoPortlet.war file and Again I created one more Portlet with name TestPortlet and here I created the Instance name as DemoPortletInstance. Which is same as above portlet which I already undeployed.

Now what is there on the admin screen. Portlet definition is created correctly but Portlet Instance is not displayed under Portlet Instances tab under Admin tab. Now If I try to create the instance name DemoPortletInstance manually then it is not creating that instance and in logs it says that instance already exists.
But I cann't use that instance in the application.

I think it is bug.

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

        

From jira-events at lists.jboss.org  Sat Jul 18 20:59:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Sat, 18 Jul 2009 20:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6919) Ensure each AS
 Service removes all of its Threads after undeployment / Server Shutdown
In-Reply-To: <30283171.1242320566711.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1031624730.1247965169274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated JBAS-6919:
--------------------------------------

    Summary: Ensure each AS Service removes all of its Threads after undeployment / Server Shutdown  (was: Ensure each AS Service leaves only Daemon Threads after Server shutdown)


> Ensure each AS Service removes all of its Threads after undeployment / Server Shutdown
> --------------------------------------------------------------------------------------
>
>                 Key: JBAS-6919
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6919
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>         Attachments: thread_dumps_after_server_shutdown.txt
>
>
> Container task.
> Server.shutdown() must take down all non-Daemon Threads run during the start lifecycle, else the VM won't be able to exit without an explicit call to Runtime.exit().

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

        

From jira-events at lists.jboss.org  Thu Jul 16 09:54:42 2009
From: jira-events at lists.jboss.org (Kevin Conner (JIRA))
Date: Thu, 16 Jul 2009 09:54:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7104) Typo in windows
 run.bat prevents inclusion of tools.jar
Message-ID: <261786877.1247752482824.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Typo in windows run.bat prevents inclusion of tools.jar
-------------------------------------------------------

                 Key: JBAS-7104
                 URL: https://jira.jboss.org/jira/browse/JBAS-7104
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Kevin Conner
            Priority: Trivial


Just noticed the following in the windows run.bat while investigating an issue.

  if "x%JAVAC_JAR%" == "x" (
    set "RUNJAR=%JAVAC_JAR%;%JBOSS_HOME%\bin\run.jar"
  ) else (
    set "RUNJAR=%JBOSS_HOME%\bin\run.jar"
  )

The set commands should be reversed.


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

        

From jira-events at lists.jboss.org  Thu Jul 16 09:23:29 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 16 Jul 2009 09:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-218) Requires property
 order even when maked as choice
Message-ID: <305663886.1247750609279.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Requires property order even when maked as choice
-------------------------------------------------

                 Key: JBXB-218
                 URL: https://jira.jboss.org/jira/browse/JBXB-218
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.1.GA
            Reporter: Thomas Diesler


Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Property order is not specified for type org.jboss.osgi.blueprint.parser.xb.TReferenceListener bound to a sequence. Property order can be specified using @XmlType.propOrder or @XmlAccessorOrder. List of properties: bean any reference refElement
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.assertPropOrderNotRequired(JBossXBNoSchemaBuilder.java:1278)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1071)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)

@XmlType(name = "TreferenceListener", namespace = BlueprintContext.XMLNS_BLUEPRINT)
public class TReferenceListener extends GTargetComponent

@XmlType(name = "GtargetComponent", namespace = BlueprintContext.XMLNS_BLUEPRINT)
@JBossXmlModelGroup(kind = JBossXmlConstants.MODEL_GROUP_CHOICE)
public class GTargetComponent extends TComponent

https://anonsvn.jboss.org/repos/jbossas/projects/jboss-osgi/trunk/reactor/bundles/blueprint/impl/src/main/java/org/jboss/osgi/blueprint/parser/xb/TReferenceListener.java

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

        

From jira-events at lists.jboss.org  Thu Jul 16 09:23:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 16 Jul 2009 09:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-210) Property order cannot
 be defined on super type
In-Reply-To: <1151868256.1246624731398.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <442398125.1247750609208.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin updated JBXB-210:
-----------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244079#4244079


> Property order cannot be defined on super type
> ----------------------------------------------
>
>                 Key: JBXB-210
>                 URL: https://jira.jboss.org/jira/browse/JBXB-210
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Thomas Diesler
>
> Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Property order is not specified for type org.jboss.osgi.blueprint.parser.xb.TReference bound to a sequence. Property order can be specified using @XmlType.propOrder or @XmlAccessorOrder. List of properties: referenceListeners dependsOn initialization componentName description any interfaceNames otherAttributes timeout filter availability
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.assertPropOrderNotRequired(JBossXBNoSchemaBuilder.java:1278)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1071)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:767)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:523)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:482)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1684)
> @XmlType(name = "Treference", namespace = BlueprintContext.XMLNS_BLUEPRINT)
> public class TReference extends TServiceReference
> @XmlType(name = "TserviceReference", namespace = BlueprintContext.XMLNS_BLUEPRINT, propOrder = { "description" })
> public class TServiceReference extends TComponent

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

        

From jira-events at lists.jboss.org  Thu Jul 16 06:18:29 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 06:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-355) offer conversion
 support for files from jBPM 3 to jBPM 4
In-Reply-To: <1159827641.1246892871401.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <927961951.1247739509306.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-355:
----------------------------

    Fix Version/s: jBPM jPDL Designer 4.1
                       (was: jBPM jPDL Designer 4.x)
         Priority: Optional  (was: Minor)


> offer conversion support for files from jBPM 3 to jBPM 4
> --------------------------------------------------------
>
>                 Key: GPD-355
>                 URL: https://jira.jboss.org/jira/browse/GPD-355
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>            Priority: Optional
>             Fix For: jBPM jPDL Designer 4.1
>
>


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

        

From jira-events at lists.jboss.org  Thu Jul 16 06:06:29 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 06:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-339) pageflow designer
In-Reply-To: <18436103.1242895977551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <84800396.1247738789836.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/GPD-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476528#action_12476528 ] 

Tom Baeyens commented on GPD-339:
---------------------------------

this only needs to be done if there are new pageflow designer requests.

as long as pageflow language in seam remains the same, the old pageflow designer can be used as is.

> pageflow designer
> -----------------
>
>                 Key: GPD-339
>                 URL: https://jira.jboss.org/jira/browse/GPD-339
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: seam
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.x
>
>
> new version of the pageflow designer

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

        

From jira-events at lists.jboss.org  Thu Jul 16 06:18:29 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 06:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-336) image generation fails
In-Reply-To: <18908917.1242894356480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1995508699.1247739509430.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-336:
----------------------------

    Fix Version/s: jBPM jPDL Designer 4.1
                       (was: jBPM jPDL Designer 4.x)
         Priority: Optional  (was: Minor)


> image generation fails
> ----------------------
>
>                 Key: GPD-336
>                 URL: https://jira.jboss.org/jira/browse/GPD-336
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>            Priority: Optional
>             Fix For: jBPM jPDL Designer 4.1
>
>
> image generation seems to work for org.jbpm.examples.async.activity
> but it seems to fail for org.jbpm.examples.async.fork.  in that case I get an image with only a diagonal line.
> koen, do you get the same with that example ?

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

        

From jira-events at lists.jboss.org  Thu Jul 16 06:10:29 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 06:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-359) Events attached to
	activities
In-Reply-To: <1291966959.1247643029123.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <739626004.1247739029562.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-359:
----------------------------

    Description: This means adding the capability of the gpd to place BPMN events on the border of activities.


> Events attached to activities 
> ------------------------------
>
>                 Key: GPD-359
>                 URL: https://jira.jboss.org/jira/browse/GPD-359
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.x
>
>
> This means adding the capability of the gpd to place BPMN events on the border of activities.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 05:58:29 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 05:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-361) analyse impact of jpdl
 changes on gpd
In-Reply-To: <70239015.1247735982202.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1116028518.1247738309237.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-361:
----------------------------

    Due Date: 21/Aug/09


> analyse impact of jpdl changes on gpd
> -------------------------------------
>
>                 Key: GPD-361
>                 URL: https://jira.jboss.org/jira/browse/GPD-361
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.1
>
>
> what type of changes can we have in jpdl that affect the gpd ?
> how will gpd deal with these changes ?

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

        

From jira-events at lists.jboss.org  Thu Jul 16 05:19:42 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 05:19:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-361) analyse impact of jpdl
 changes on gpd
Message-ID: <70239015.1247735982202.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

analyse impact of jpdl changes on gpd
-------------------------------------

                 Key: GPD-361
                 URL: https://jira.jboss.org/jira/browse/GPD-361
             Project: JBoss jBPM GPD
          Issue Type: Task
            Reporter: Tom Baeyens
            Assignee: Koen Aers
             Fix For: jBPM jPDL Designer 4.1


what type of changes can we have in jpdl that affect the gpd ?
how will gpd deal with these changes ?

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

        

From jira-events at lists.jboss.org  Thu Jul 16 05:56:30 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 05:56:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-353) contribute xsd to xml
 catalog (xsd dependent on runtime)
In-Reply-To: <22572021.1244570156492.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1430302545.1247738190201.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-353:
----------------------------

    Due Date: 07/Aug/09


> contribute xsd to xml catalog (xsd dependent on runtime)
> --------------------------------------------------------
>
>                 Key: GPD-353
>                 URL: https://jira.jboss.org/jira/browse/GPD-353
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.1
>
>
> this has to happen when the jBPM runtime is configured in the general jBPM preferences

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

        

From jira-events at lists.jboss.org  Thu Jul 16 05:34:29 2009
From: jira-events at lists.jboss.org (Alexander Lengson (JIRA))
Date: Thu, 16 Jul 2009 05:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7103) Hot deployment woks
 incorrectly on the EE project without deployment descriptors
Message-ID: <1370254810.1247736869351.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Hot deployment woks incorrectly on the EE project without deployment descriptors
--------------------------------------------------------------------------------

                 Key: JBAS-7103
                 URL: https://jira.jboss.org/jira/browse/JBAS-7103
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Deployers
    Affects Versions: JBossAS-5.0.1.GA
         Environment: Windows XP SP3 
JBoss AS: 5.0.1.GA
Eclipse 3.5: eclipse-jee-galileo-win32.zip 
JBossTools : 3.0.1.GA JBossTools-ALL-win32-3.0.1.GA-R200905070146-H18.zip 

            Reporter: Alexander Lengson
            Assignee: Ales Justin


JBoss AS 5.0.1.GA does not redeploy new EJB written over old one when EJB JAR does not contain deployment descriptors and EJB is deployed as an exploded folder, not single-file archive.
As discussed in another issue (https://jira.jboss.org/jira/browse/JBIDE-4608), this is because of JBoss AS redeploys EJB if its descriptor is touched. Simple changing .class file is not enough to make JBoss redeploy the EJB, but in the case when there is no deployment descriptor (everything is configured via annotations), nothing may cause redeploy (except full remove and new publish)

Workaround is to have deployment descriptors in the module.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 05:56:30 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 05:56:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-353) contribute xsd to xml
 catalog (xsd dependent on runtime)
In-Reply-To: <22572021.1244570156492.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1976155975.1247738190125.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-353:
----------------------------

    Description: this has to happen when the jBPM runtime is configured in the general jBPM preferences


> contribute xsd to xml catalog (xsd dependent on runtime)
> --------------------------------------------------------
>
>                 Key: GPD-353
>                 URL: https://jira.jboss.org/jira/browse/GPD-353
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.1
>
>
> this has to happen when the jBPM runtime is configured in the general jBPM preferences

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

        

From jira-events at lists.jboss.org  Thu Jul 16 05:39:29 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 05:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-358) Create jBPM Project
 Configuration Wizard
In-Reply-To: <497794165.1247499509147.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <91101615.1247737169390.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-358:
----------------------------

    Fix Version/s: jBPM jPDL Designer 4.x
                       (was: jBPM jPDL Designer 4.1)


> Create jBPM Project Configuration Wizard
> ----------------------------------------
>
>                 Key: GPD-358
>                 URL: https://jira.jboss.org/jira/browse/GPD-358
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.x
>
>
> This wizard can be launched from the project popup menu in the Java/J2EE/Resources perspective. It will import all the libraries from the currently configured runtime.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 05:37:29 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 05:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-357) Error while validating
 jPDL file: Problem class was moved from API
In-Reply-To: <985295068.1247498249570.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2003035359.1247737049132.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-357:
----------------------------

       Due Date: 24/Jul/09
    Description: 
1) Fix the dynamic loading problem of the problem class that has moved

2) Add automatic validation activation in the background


> Error while validating jPDL file: Problem class was moved from API
> ------------------------------------------------------------------
>
>                 Key: GPD-357
>                 URL: https://jira.jboss.org/jira/browse/GPD-357
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM jPDL Designer 4.0.0.GA
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.1
>
>
> 1) Fix the dynamic loading problem of the problem class that has moved
> 2) Add automatic validation activation in the background

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

        

From jira-events at lists.jboss.org  Thu Jul 16 05:54:29 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 05:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-358) Create jBPM Project
 Configuration Wizard
In-Reply-To: <497794165.1247499509147.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2073646231.1247738069497.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-358:
----------------------------

    Description: 
This wizard can be launched from the project popup menu in the Java/J2EE/Resources perspective. 

A project configuration will offered and includes
 - a selection of the configured jBPM runtimes
 - a checkbox to import all the jBPM Libraries

  was:This wizard can be launched from the project popup menu in the Java/J2EE/Resources perspective. It will import all the libraries from the currently configured runtime.



> Create jBPM Project Configuration Wizard
> ----------------------------------------
>
>                 Key: GPD-358
>                 URL: https://jira.jboss.org/jira/browse/GPD-358
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.x
>
>
> This wizard can be launched from the project popup menu in the Java/J2EE/Resources perspective. 
> A project configuration will offered and includes
>  - a selection of the configured jBPM runtimes
>  - a checkbox to import all the jBPM Libraries

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

        

From jira-events at lists.jboss.org  Thu Jul 16 05:39:29 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 05:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-356) Designer creates
 duplicate handler nodes under decision nodes
In-Reply-To: <2099402771.1247492381837.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <697166806.1247737169511.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-356:
----------------------------

    Due Date: 07/Aug/09
    Priority: Major  (was: Minor)


> Designer creates duplicate handler nodes under decision nodes
> -------------------------------------------------------------
>
>                 Key: GPD-356
>                 URL: https://jira.jboss.org/jira/browse/GPD-356
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM jPDL Designer 4.0.0.GA
>            Reporter: Alfie Kirkpatrick
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.1
>
>
> When switching between text mode and graphical mode and saving the process definition a few times a large number of handler elements can build up under each decision node. This doesn't seem to affect the running of the process so is more an inconvenience than anything, but could cause confusion if the handler parameters are modified.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 04:27:29 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 16 Jul 2009 04:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-89) The implementation
 of isInheritable() in CtNewClass is wrong.
Message-ID: <32388671.1247732849414.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

The implementation of isInheritable() in CtNewClass is wrong.
-------------------------------------------------------------

                 Key: JASSIST-89
                 URL: https://jira.jboss.org/jira/browse/JASSIST-89
             Project: Javassist
          Issue Type: Bug
    Affects Versions: 3.11.0.GA
            Reporter: Shigeru Chiba
            Assignee: Shigeru Chiba
             Fix For: 3.12.0.GA


In CtNewClass,

private boolean isInheritable(int mod, CtClass superclazz) {
        if (Modifier.isPrivate(mod))
            return false;

        if (Modifier.isPackage(mod)) {
            String pname = getPackageName();
            String pname2 = superclazz.getPackageName();
            if (pname == null)
                return pname2 == null;
            else
                pname.equals(pname2);        // <==== should return pname.equals(pname2)
        }

        return true;
    }

Originally reported by Michihiro Horie


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

        

From jira-events at lists.jboss.org  Thu Jul 16 04:35:41 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 16 Jul 2009 04:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-89) The implementation
 of isInheritable() in CtNewClass is wrong.
In-Reply-To: <32388671.1247732849414.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1075076395.1247733341983.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-89.
----------------------------------

    Resolution: Done


> The implementation of isInheritable() in CtNewClass is wrong.
> -------------------------------------------------------------
>
>                 Key: JASSIST-89
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-89
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.11.0.GA
>            Reporter: Shigeru Chiba
>            Assignee: Shigeru Chiba
>             Fix For: 3.12.0.GA
>
>
> In CtNewClass,
> private boolean isInheritable(int mod, CtClass superclazz) {
>         if (Modifier.isPrivate(mod))
>             return false;
>         if (Modifier.isPackage(mod)) {
>             String pname = getPackageName();
>             String pname2 = superclazz.getPackageName();
>             if (pname == null)
>                 return pname2 == null;
>             else
>                 pname.equals(pname2);        // <==== should return pname.equals(pname2)
>         }
>         return true;
>     }
> Originally reported by Michihiro Horie

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

        

From jira-events at lists.jboss.org  Thu Jul 16 04:35:42 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 16 Jul 2009 04:35:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JASSIST-89) The implementation
 of isInheritable() in CtNewClass is wrong.
In-Reply-To: <32388671.1247732849414.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <27105947.1247733342096.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba closed JASSIST-89.
--------------------------------



> The implementation of isInheritable() in CtNewClass is wrong.
> -------------------------------------------------------------
>
>                 Key: JASSIST-89
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-89
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.11.0.GA
>            Reporter: Shigeru Chiba
>            Assignee: Shigeru Chiba
>             Fix For: 3.12.0.GA
>
>
> In CtNewClass,
> private boolean isInheritable(int mod, CtClass superclazz) {
>         if (Modifier.isPrivate(mod))
>             return false;
>         if (Modifier.isPackage(mod)) {
>             String pname = getPackageName();
>             String pname2 = superclazz.getPackageName();
>             if (pname == null)
>                 return pname2 == null;
>             else
>                 pname.equals(pname2);        // <==== should return pname.equals(pname2)
>         }
>         return true;
>     }
> Originally reported by Michihiro Horie

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

        

From jira-events at lists.jboss.org  Thu Jul 16 04:17:30 2009
From: jira-events at lists.jboss.org (Martin Burger (JIRA))
Date: Thu, 16 Jul 2009 04:17:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-88) It is not possible
 to instrument class Object because of: [source error] cannot find the super
 class of java.lang.Object
Message-ID: <1295983700.1247732250014.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

It is not possible to instrument class Object because of: [source error] cannot find the super class of java.lang.Object
------------------------------------------------------------------------------------------------------------------------

                 Key: JASSIST-88
                 URL: https://jira.jboss.org/jira/browse/JASSIST-88
             Project: Javassist
          Issue Type: Bug
    Affects Versions: 3.10.0.GA
            Reporter: Martin Burger
            Assignee: Shigeru Chiba


I would like to instrument the constructor in class Object. However, class MemberResolver (part of Javassist's compiler) cannot find its superclass. Of course, there is no superclass.

Exception:

javassist.CannotCompileException: [source error] cannot find the super class of java.lang.Object
	at javassist.CtBehavior.setBody(CtBehavior.java:368)
	at javassist.CtBehavior.setBody(CtBehavior.java:334)
	at javassist.CtConstructor.setBody(CtConstructor.java:216)
	at de.unisb.cs.st.deltadebugging.jinsi.agent.capture.CaptureAgent.premain(CaptureAgent.java:33)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	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 sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:323)
	at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:338)
Caused by: compile error: cannot find the super class of java.lang.Object
	at javassist.compiler.MemberResolver.getSuperclass(MemberResolver.java:490)
	at javassist.compiler.MemberCodeGen.insertDefaultSuperCall(MemberCodeGen.java:80)
	at javassist.compiler.CodeGen.atMethodBody(CodeGen.java:288)
	at javassist.compiler.Javac.compileBody(Javac.java:222)
	at javassist.CtBehavior.setBody(CtBehavior.java:360)
	... 9 more

In javassist.compiler.CodeGen.atMethodBody(Stmnt, boolean, boolean) the call to method javassist.compiler.CodeGen.needsSuperCall(Stmnt) should return false instead of true, I assume. At least this seems to be the location where this bug could be fixed.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 04:37:45 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 16 Jul 2009 04:37:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1178330750.1247733465069.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1011:
---------------------------

    Fix Version/s: 2.6.11


> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

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

        

From jira-events at lists.jboss.org  Thu Jul 16 04:47:29 2009
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 16 Jul 2009 04:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-141) Servlet Filter
 against XSS and CSRF
Message-ID: <1119010745.1247734049221.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBWEB-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476520#action_12476520 ] 

Dimitris Andreadis commented on JBWEB-141:
------------------------------------------

Marc, maybe you contribute/test such a filter for JBossWeb yourself?

> Servlet Filter against XSS and CSRF
> -----------------------------------
>
>                 Key: JBWEB-141
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-141
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Marc Schoenefeld
>            Assignee: Remy Maucherat
>            Priority: Minor
>
> Cross-Site scripting and cross-site request forgery attacks are common threat to every web application. 
> So a common solution offered by the http server is helpful to raise the default protection level. 
> A servlet filter will help to  
> a) allow/block requests for a set of XSS regex patterns (per default blacklist suspicious parameter patterns, and optionally whitelist valid requests for well-known applications)  
> b) allow/block requests that fulfil the criteria for being a forged request (failing nonce compare), this will need a javascript helper on the client side, to transparently protect existing applications to provide the shared secret in the session . 

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

        

From jira-events at lists.jboss.org  Thu Jul 16 01:38:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 16 Jul 2009 01:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <450715898.1247722709495.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1685:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA
                       (was: 1.4.3.GA)


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

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

        

From jira-events at lists.jboss.org  Wed Jul 15 23:40:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 23:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1631) Messages are
 piling up in the queues in clustered environment and not pulled by message
 sucker
In-Reply-To: <30545717.1242929996483.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1692926756.1247715629782.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1631:
------------------------------------

    Attachment: 1631-test-source.zip


> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1631
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP08
>         Environment: Cluster of a few JBoss 4.2.3 servers with JBM 1.4.2.GA-SP1 or 1.4.0.SP3_CP08 running on x64 windows servers.
> JBoss Remoting 2.5.1 or 2.2.3
> Clustered XA connection factory, clustered queues, both server and client (MDBs) are deployed as one application - identical deployment for all servers in a cluster
>            Reporter: Victor Starenky
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 1631-test-source.zip, logs-and-config-prod.zip, logs-and-config-test.zip, TestRecommendationSentProcessorMDB.java
>
>
> We have an EJB3 application is running on a cluster of 7 servers. 
> All servers have the same application farmed across them. 
> We have a clustered queue and using clustered connection factory.
> Originally we ran into the bug JBMESSAGING-1456 and while testing the fix ran into a different problem. After the cluster was running for some time (usually overnight with lots of heavy background processing hapenning at that time) we see messages are "piling up" in some queues on some nodes.
> Sympthoms are:
> MessageCount is not zero (rather in the order of hundreeds), DeliveringCount is zero. These nodes have ConsumerCount=0 for the queues experiencing the problem. Message sucker is configured as far as I can tell. Looks like the problem might be related to client and/or server failover leaving some nodes without consumers while sucker not doing it's job (if I understand it correctly). 
> Once we bump the timeout values much higher than they are in the original config files the problem seems to disappear or at least show up much less frequently. Specifically I'm talking about these values:
> messaging-service.xml:
>       <attribute name="FailoverStartTimeout">180000</attribute>
> remoting-bisocket-service.xml:
>                <attribute name="clientLeasePeriod" isParam="true">30000</attribute>
>                <attribute name="validatorPingPeriod" isParam="true">30000</attribute>
>                <attribute name="validatorPingTimeout" isParam="true">20000</attribute>
>                <attribute name="registerCallbackListener">false</attribute>
>                <attribute name="timeout" isParam="true">240000</attribute>
> While this serves as a temporary workaround we don't feel we can rely on JBM in a production clustered environment without having failover working properly.
> This is a big showstopper for us at the moment.
> Attached are the log files from the prod environment of 7 servers with the config files as well as log files from the test environment with just 2 servers (having same issue) and corresponding configs. The logs were produced by the test version of the messaging code with added logging as per JBMESSAGING-1456.

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

        

From jira-events at lists.jboss.org  Wed Jul 15 23:40:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 23:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1631) Messages
 are piling up in the queues in clustered environment and not pulled by
 message sucker
In-Reply-To: <30545717.1242929996483.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1982744325.1247715629589.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476495#action_12476495 ] 

Howard Gao commented on JBMESSAGING-1631:
-----------------------------------------

Hi Hossein,

I still can't reproduce it in my env. I changed the MDB to use Topic and send messaged every 10 minutes, and 2000 messages for each sending. It looks like both MDB got all the messages in the overnight test.

I'm uploading my test source (1631-test-source.zip), can you help me how to get this reproduced? Thanks.

Howard


> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1631
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP08
>         Environment: Cluster of a few JBoss 4.2.3 servers with JBM 1.4.2.GA-SP1 or 1.4.0.SP3_CP08 running on x64 windows servers.
> JBoss Remoting 2.5.1 or 2.2.3
> Clustered XA connection factory, clustered queues, both server and client (MDBs) are deployed as one application - identical deployment for all servers in a cluster
>            Reporter: Victor Starenky
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 1631-test-source.zip, logs-and-config-prod.zip, logs-and-config-test.zip, TestRecommendationSentProcessorMDB.java
>
>
> We have an EJB3 application is running on a cluster of 7 servers. 
> All servers have the same application farmed across them. 
> We have a clustered queue and using clustered connection factory.
> Originally we ran into the bug JBMESSAGING-1456 and while testing the fix ran into a different problem. After the cluster was running for some time (usually overnight with lots of heavy background processing hapenning at that time) we see messages are "piling up" in some queues on some nodes.
> Sympthoms are:
> MessageCount is not zero (rather in the order of hundreeds), DeliveringCount is zero. These nodes have ConsumerCount=0 for the queues experiencing the problem. Message sucker is configured as far as I can tell. Looks like the problem might be related to client and/or server failover leaving some nodes without consumers while sucker not doing it's job (if I understand it correctly). 
> Once we bump the timeout values much higher than they are in the original config files the problem seems to disappear or at least show up much less frequently. Specifically I'm talking about these values:
> messaging-service.xml:
>       <attribute name="FailoverStartTimeout">180000</attribute>
> remoting-bisocket-service.xml:
>                <attribute name="clientLeasePeriod" isParam="true">30000</attribute>
>                <attribute name="validatorPingPeriod" isParam="true">30000</attribute>
>                <attribute name="validatorPingTimeout" isParam="true">20000</attribute>
>                <attribute name="registerCallbackListener">false</attribute>
>                <attribute name="timeout" isParam="true">240000</attribute>
> While this serves as a temporary workaround we don't feel we can rely on JBM in a production clustered environment without having failover working properly.
> This is a big showstopper for us at the moment.
> Attached are the log files from the prod environment of 7 servers with the config files as well as log files from the test environment with just 2 servers (having same issue) and corresponding configs. The logs were produced by the test version of the messaging code with added logging as per JBMESSAGING-1456.

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

        

From jira-events at lists.jboss.org  Sat Jul 18 17:49:41 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Jul 2009 17:49:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7055)
 testValidateSBMContent having problems with hostnames
In-Reply-To: <3567712.1245871496476.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <613523752.1247953781665.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned JBAS-7055:
--------------------------------------

    Assignee: Brian Stansberry  (was: Scott M Stark)


> testValidateSBMContent having problems with hostnames 
> ------------------------------------------------------
>
>                 Key: JBAS-7055
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7055
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Solaris 9/10 both x86 and sparc
> HPUX both ia64 and risc 
>            Reporter: Richard Achmatowicz
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> See the JBPAPP-2139 issue for details.

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

        

From jira-events at lists.jboss.org  Sat Jul 18 19:04:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Jul 2009 19:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7055)
 testValidateSBMContent having problems with hostnames
In-Reply-To: <3567712.1245871496476.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1333786539.1247958269217.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7055.
----------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1
       Resolution: Done


Just a test problem.

> testValidateSBMContent having problems with hostnames 
> ------------------------------------------------------
>
>                 Key: JBAS-7055
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7055
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Solaris 9/10 both x86 and sparc
> HPUX both ia64 and risc 
>            Reporter: Richard Achmatowicz
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> See the JBPAPP-2139 issue for details.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 16:50:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 20 Jul 2009 16:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
In-Reply-To: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <488220440.1248123029391.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7108:
-------------------------------

        Fix Version/s: JBossAS-5.2.0.Beta1
    Affects Version/s: JBossAS-5.1.0.GA
                           (was: JBossAS-5.2.0.Beta1)
               Labels: embjopr1_3 managedobjects  (was: )


> Unable to collect EJB3 invocation statistics
> --------------------------------------------
>
>                 Key: JBAS-7108
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:
> java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 16:54:29 2009
From: jira-events at lists.jboss.org (Gurkan Erdogdu (JIRA))
Date: Mon, 20 Jul 2009 16:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-112) Adding Partial
 Implementation for Specification Chapter11
In-Reply-To: <546837010.1247330860697.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <774631584.1248123269263.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gurkan Erdogdu updated JBJCA-112:
---------------------------------

    Attachment: commonProject_last.patch
                coreProject_last.patch
                coreTest_last.patch


Update of the patches. Changes to WorkManagerImpl to remove duplicates and tidy up code. Update WorkWrapper to reflect "WorkContext" setup.

Please review my patch before updating repo.

Thanks;

--Gurkan

> Adding Partial Implementation for Specification Chapter11
> ---------------------------------------------------------
>
>                 Key: JBJCA-112
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-112
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Core
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>         Attachments: CommonProject.diff, CommonProject.patch, commonProject_last.patch, CoreProject.diff, CoreProject.patch, coreProject_last.patch, CoreProjectTest.patch, CoreTest.diff, coreTest_last.patch
>
>
> I have implemented some of checks that are defined in the specification Chapter 11.
> 3 different patches exist
> 1* CommonProject.diff --> Contains utility class.
> 2* CoreProject.diff --> Updating WorkWrapper and WorkManagerImpl to support WorkContextProvider
> 3* CoreTest.diff --> Updating tests for Chapter 11

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

        

From jira-events at lists.jboss.org  Mon Jul 20 17:18:41 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 17:18:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1872)
 InvocationStats.reset does not clear out methods invoked
Message-ID: <1375204373.1248124721318.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

InvocationStats.reset does not clear out methods invoked
--------------------------------------------------------

                 Key: EJBTHREE-1872
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1872
             Project: EJB 3.0
          Issue Type: Bug
          Components: core
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 1.1.10


Currently the reset operation simply clears the invocation times on each of the methods in the method map.  We should be clearing the map entirely.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 17:22:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 17:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1873) MDB inflow
 invocation does not record InvocationStatistics
Message-ID: <77794088.1248124949153.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

MDB inflow invocation does not record InvocationStatistics
----------------------------------------------------------

                 Key: EJBTHREE-1873
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1873
             Project: EJB 3.0
          Issue Type: Bug
          Components: core
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 1.1.10


Wire up the MessageInflow mechanism to record Invocation Statistics

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

        

From jira-events at lists.jboss.org  Mon Jul 20 17:24:42 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 17:24:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1873) MDB inflow
 invocation does not record InvocationStatistics
In-Reply-To: <77794088.1248124949153.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <39035168.1248125082137.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved EJBTHREE-1873.
-------------------------------------------

    Resolution: Done


> MDB inflow invocation does not record InvocationStatistics
> ----------------------------------------------------------
>
>                 Key: EJBTHREE-1873
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1873
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.10
>
>
> Wire up the MessageInflow mechanism to record Invocation Statistics

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

        

From jira-events at lists.jboss.org  Mon Jul 20 17:24:42 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 17:24:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1872)
 InvocationStats.reset does not clear out methods invoked
In-Reply-To: <1375204373.1248124721318.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2130405619.1248125082233.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved EJBTHREE-1872.
-------------------------------------------

    Resolution: Done


> InvocationStats.reset does not clear out methods invoked
> --------------------------------------------------------
>
>                 Key: EJBTHREE-1872
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1872
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.10
>
>
> Currently the reset operation simply clears the invocation times on each of the methods in the method map.  We should be clearing the map entirely.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 17:26:29 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 20 Jul 2009 17:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-140) JBoss STS - add a
 ClaimsHandler interface that allows for pluggable claims interpreters
Message-ID: <631663045.1248125189514.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss STS - add a ClaimsHandler interface that allows for pluggable claims interpreters
---------------------------------------------------------------------------------------

                 Key: JBID-140
                 URL: https://jira.jboss.org/jira/browse/JBID-140
             Project: JBoss Identity
          Issue Type: Task
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha3
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: IDFED-1.0.0.alpha4


A WS-Trust request may contain a set of claims that must be included in the issued token. The claims syntax is not specified, so it must be inferred from the Dialect attribute of the Claims element. We must create a ClaimsHandler or ClaimsProvider interface in the STS system to allow for pluggable configuration of claim handlers.

A possible default implementation could handle claims as specified by the Identity Metasystem Interoperability 1.0 (http://docs.oasis-open.org/imi/ns/identity-200810) and use the JBoss IDM API to obtain the necessary information.

The configuration of the ClaimsHandlers would be similar to the TokeProviders and should also allow for the specification of general properties:

<ClaimsHandlers>
   <ClaimsHandler HandlerClass="...." ClaimsDialect="http://....">
       <Property name="prop" value="value"/>
   </ClaimsHandler>
</ClaimsHandler>

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

        

From jira-events at lists.jboss.org  Mon Jul 20 17:26:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 17:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
In-Reply-To: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <432678983.1248125189448.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476918#action_12476918 ] 

Andrew Lee Rubinger commented on JBAS-7108:
-------------------------------------------

Updated the test case to show the errors.  Resolved the linked dependent issues.  Must release EJB3 and integrate into Branch_5_x, then merge into JBPAPP.

> Unable to collect EJB3 invocation statistics
> --------------------------------------------
>
>                 Key: JBAS-7108
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:
> java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 17:33:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 17:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1874) MDBs must expose
 invocation statistics
Message-ID: <1141295772.1248125609236.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

MDBs must expose invocation statistics
--------------------------------------

                 Key: EJBTHREE-1874
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1874
             Project: EJB 3.0
          Issue Type: Bug
          Components: metrics-deployer
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 1.1.10


Refactor such that invocation statistics are included in the EJB3 MDB ManagmentObject view

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

        

From jira-events at lists.jboss.org  Mon Jul 20 17:35:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 17:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1874) MDBs must
 expose invocation statistics
In-Reply-To: <1141295772.1248125609236.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <462466904.1248125729169.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved EJBTHREE-1874.
-------------------------------------------

    Resolution: Done


> MDBs must expose invocation statistics
> --------------------------------------
>
>                 Key: EJBTHREE-1874
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1874
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: metrics-deployer
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.10
>
>
> Refactor such that invocation statistics are included in the EJB3 MDB ManagmentObject view

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

        

From jira-events at lists.jboss.org  Mon Jul 20 17:39:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 17:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1831) Clean up
	dependency chains
In-Reply-To: <13433231.1242136368008.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1037790424.1248125969316.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated EJBTHREE-1831:
------------------------------------------

    Fix Version/s:     (was: 1.1.10)


> Clean up dependency chains
> --------------------------
>
>                 Key: EJBTHREE-1831
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1831
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: as-int, ejb3
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>
> The true order should be:
> jboss-ejb3 > as-int > AS
> jboss-ejb3 > Plugin
> Whereas now as-int goes into Plugin.  Also endpoint-deployer should be included in as-int and Plugin, and not explicitly declared by AS itself.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 17:39:29 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 20 Jul 2009 17:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-141) JBoss STS - add
 logging to the STS classes
Message-ID: <209311878.1248125969341.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss STS - add logging to the STS classes
------------------------------------------

                 Key: JBID-141
                 URL: https://jira.jboss.org/jira/browse/JBID-141
             Project: JBoss Identity
          Issue Type: Task
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha3
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: IDFED-1.0.0.alpha4


We need to log the important events in the STS classes using the appropriate log levels.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 17:39:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 17:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1875) Align
 dependencies for 1.1.10 release
Message-ID: <448858236.1248125969494.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Align dependencies for 1.1.10 release
-------------------------------------

                 Key: EJBTHREE-1875
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1875
             Project: EJB 3.0
          Issue Type: Task
          Components: as-int, ejb3, metrics-deployer
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 1.1.10


Tracking issue for updates to the poms of projects in the release chain

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

        

From jira-events at lists.jboss.org  Mon Jul 20 17:45:29 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 20 Jul 2009 17:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBID-83) Implement token
 encryption (symmetric and public key)
Message-ID: <1905059177.1248126329221.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen deleted JBID-83:
-------------------------------


> Implement token encryption (symmetric and public key)
> -----------------------------------------------------
>
>                 Key: JBID-83
>                 URL: https://jira.jboss.org/jira/browse/JBID-83
>             Project: JBoss Identity
>          Issue Type: Task
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>
> The request handler must encrypt the tokens generated by the security token provider when needed. We may use the XML Sec API to encrypt the returned tokens.
> Need to look for the XML Signature/Encryption utility for this.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 17:55:29 2009
From: jira-events at lists.jboss.org (Marcel Kolsteren (JIRA))
Date: Mon, 20 Jul 2009 17:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBID-132) redirect binding
 computes incorrect signatures for SAML responses
In-Reply-To: <1330676091.1247682749094.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1207740718.1248126929234.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcel Kolsteren resolved JBID-132.
-----------------------------------

    Fix Version/s: IDFED-1.0.0.alpha4
       Resolution: Done


Fixed by svn revision 654.

> redirect binding computes incorrect signatures for SAML responses
> -----------------------------------------------------------------
>
>                 Key: JBID-132
>                 URL: https://jira.jboss.org/jira/browse/JBID-132
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Marcel Kolsteren
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>         Attachments: JBID-132.txt
>
>
> When using the HTTP/Redirect binding with signature support, the signatures for SAMLResponse messages are incorrect. This is caused by the computeSignature method in the RedirectBindingSignatureUtil. This method is called for requests as well as for responses, but when it constructs the string that needs to be signed, it always uses "SAMLRequest":
>       sb.append("SAMLRequest=").append(urlEncodedRequest);

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

        

From jira-events at lists.jboss.org  Mon Jul 20 17:57:29 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 20 Jul 2009 17:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7037) JBossAS 5.x fails
 to use EJB's security domain in jboss.xml when the call is from web
 container
In-Reply-To: <2821553.1245299576703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <897103715.1248127049572.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476922#action_12476922 ] 

Stefan Guilhen commented on JBAS-7037:
--------------------------------------

I've been able to reproduce the error and my preliminary investigation shows that calls made by remote clients directly to the EJBs are being secured as expected. However, when a call is made from a Servlet, the EJB security uses the Web App's domain instead of the domain that has been set in jboss.xml. I'll run the server in debug mode and see if I can figure out why this is happening.

> JBossAS 5.x fails to use EJB's security domain in jboss.xml when the call is from web container
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7037
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7037
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>         Environment: Problem found on Windows platform
>            Reporter: Calvin Lin
>            Assignee: Stefan Guilhen
>             Fix For: JBossAS-5.0.2.GA
>
>         Attachments: ConfigFiles-lib.zip, JBAS-jira-authenBug.zip
>
>
> A degredation from JBoss 4.0.x and 4.2.x to JBoss 5.0.1.GA and JBoss 5.1.0.GA.
> We noticed that the JAAS login in EJB container always picks up the Web app's security domain when the client login is originated from a web application client.  The security domain specified in EJB container's jboss.xml is always ignored in this situation.
> The detailed problem description is posted on JBoss forum:
> http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156863

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

        

From jira-events at lists.jboss.org  Mon Jul 20 18:01:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 18:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1875) Align
 dependencies for 1.1.10 release
In-Reply-To: <448858236.1248125969494.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2020947794.1248127289152.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger reassigned EJBTHREE-1875:
---------------------------------------------

    Assignee: jaikiran pai  (was: Andrew Lee Rubinger)


Sending to Jaikiran to put the nail in the coffin for ejb3-plugin

> Align dependencies for 1.1.10 release
> -------------------------------------
>
>                 Key: EJBTHREE-1875
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1875
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: as-int, ejb3, metrics-deployer
>            Reporter: Andrew Lee Rubinger
>            Assignee: jaikiran pai
>             Fix For: 1.1.10
>
>
> Tracking issue for updates to the poms of projects in the release chain

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

        

From jira-events at lists.jboss.org  Mon Jul 20 18:06:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 18:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1875) Align
 dependencies for 1.1.10 release
In-Reply-To: <448858236.1248125969494.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2135634806.1248127589312.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved EJBTHREE-1875.
-------------------------------------------

    Resolution: Done


> Align dependencies for 1.1.10 release
> -------------------------------------
>
>                 Key: EJBTHREE-1875
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1875
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: as-int, ejb3, metrics-deployer
>            Reporter: Andrew Lee Rubinger
>            Assignee: jaikiran pai
>             Fix For: 1.1.10
>
>
> Tracking issue for updates to the poms of projects in the release chain

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

        

From jira-events at lists.jboss.org  Mon Jul 20 18:06:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 20 Jul 2009 18:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-132) redirect binding
 computes incorrect signatures for SAML responses
In-Reply-To: <1330676091.1247682749094.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1085436292.1248127589428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-132:
-------------------------------

    Fix Version/s: IDFED-1.0.0.beta1
                       (was: IDFED-1.0.0.alpha4)


> redirect binding computes incorrect signatures for SAML responses
> -----------------------------------------------------------------
>
>                 Key: JBID-132
>                 URL: https://jira.jboss.org/jira/browse/JBID-132
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Marcel Kolsteren
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>         Attachments: JBID-132.txt
>
>
> When using the HTTP/Redirect binding with signature support, the signatures for SAMLResponse messages are incorrect. This is caused by the computeSignature method in the RedirectBindingSignatureUtil. This method is called for requests as well as for responses, but when it constructs the string that needs to be signed, it always uses "SAMLRequest":
>       sb.append("SAMLRequest=").append(urlEncodedRequest);

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

        

From jira-events at lists.jboss.org  Mon Jul 20 18:10:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 18:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7111) Upgrade AS to EJB3
	1.1.10
Message-ID: <1342595127.1248127829114.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade AS to EJB3 1.1.10
-------------------------

                 Key: JBAS-7111
                 URL: https://jira.jboss.org/jira/browse/JBAS-7111
             Project: JBoss Application Server
          Issue Type: Thirdparty Change
      Security Level: Public (Everyone can see)
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


Component Upgrade

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

        

From jira-events at lists.jboss.org  Mon Jul 20 18:44:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 18:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7111) Upgrade AS to EJB3
	1.1.10
In-Reply-To: <1342595127.1248127829114.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1579760812.1248129869174.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBAS-7111.
---------------------------------------

    Resolution: Done


> Upgrade AS to EJB3 1.1.10
> -------------------------
>
>                 Key: JBAS-7111
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7111
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Component Upgrade

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

        

From jira-events at lists.jboss.org  Mon Jul 20 18:44:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 18:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7112) EJB3 Metrics Test
 Failing in trunk
Message-ID: <1445531349.1248129869264.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

EJB3 Metrics Test Failing in trunk
----------------------------------

                 Key: JBAS-7112
                 URL: https://jira.jboss.org/jira/browse/JBAS-7112
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: JBossAS-6.0.0.Alpha1


Managed Component not getting deployed?

junit.framework.AssertionFailedError: Component not found; no managed object with name "testEjb3xMetrics.jar/TestLoggingMDB" in: []
	at org.jboss.test.profileservice.test.Ejb3MetricsUnitTestCase.getAndTestManagedComponent(Ejb3MetricsUnitTestCase.java:416)
	at org.jboss.test.profileservice.test.Ejb3MetricsUnitTestCase.testMdb(Ejb3MetricsUnitTestCase.java:319)



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

        

From jira-events at lists.jboss.org  Mon Jul 20 18:46:42 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 18:46:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
In-Reply-To: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1697276799.1248130002572.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBAS-7108.
---------------------------------------

    Resolution: Done


Tests passing in Branch_5_x.  Failing in trunk for unrelated reasons; @see JBAS-7112 for that.

> Unable to collect EJB3 invocation statistics
> --------------------------------------------
>
>                 Key: JBAS-7108
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:
> java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 18:48:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 18:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
In-Reply-To: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2118850283.1248130109285.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476926#action_12476926 ] 

Andrew Lee Rubinger commented on JBAS-7108:
-------------------------------------------

If this needs to go to JBPAPP, please get approval and open a JBPAPP issue.

> Unable to collect EJB3 invocation statistics
> --------------------------------------------
>
>                 Key: JBAS-7108
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:
> java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 18:52:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 20 Jul 2009 18:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-119) Hibernate Validator
	4.0.0Beta2
In-Reply-To: <1098713284.1247792429189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1101195032.1248130349189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang updated JBJCA-119:
-----------------------------

    Summary: Hibernate Validator 4.0.0Beta2  (was: Hibernate Validator 4.0.0Beta1)


update to beta2, reference:
http://in.relation.to/Bloggers/RoadToFinalBeanValidationPFD2AndItsImplementationHibernateValidator4Beta2

> Hibernate Validator 4.0.0Beta2
> ------------------------------
>
>                 Key: JBJCA-119
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-119
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> for 303 requirement 

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

        

From jira-events at lists.jboss.org  Mon Jul 20 19:06:29 2009
From: jira-events at lists.jboss.org (Alexandre Navarro (JIRA))
Date: Mon, 20 Jul 2009 19:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-362) The textfield name for
 a state/task for does not work correctly (insert mode enabled)
Message-ID: <1818801381.1248131189718.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

The textfield name for a state/task for does not work correctly (insert mode enabled)
-------------------------------------------------------------------------------------

                 Key: GPD-362
                 URL: https://jira.jboss.org/jira/browse/GPD-362
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM jPDL Designer 4.0.0.GA
            Reporter: Alexandre Navarro
            Assignee: Koen Aers
            Priority: Critical


When you type the name of a state or task on the properties view, the textfield is insert mode, so the name will exactly the reverse 

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

        

From jira-events at lists.jboss.org  Mon Jul 20 19:08:42 2009
From: jira-events at lists.jboss.org (Alexandre Navarro (JIRA))
Date: Mon, 20 Jul 2009 19:08:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-363) Name of Decision box
 are not visible on the grahi.
Message-ID: <2001374101.1248131322839.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Name of Decision box are not visible on the grahi.
--------------------------------------------------

                 Key: GPD-363
                 URL: https://jira.jboss.org/jira/browse/GPD-363
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM jPDL Designer 4.0.0.GA
            Reporter: Alexandre Navarro
            Assignee: Koen Aers
            Priority: Critical


Name of Decision box are not visible on the grahi.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 23:18:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 20 Jul 2009 23:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1689) Pass
 trustStore parameters to remoting layer
In-Reply-To: <369523920.1248073853274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1996232702.1248146309266.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1689:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> Pass trustStore parameters to remoting layer
> --------------------------------------------
>
>                 Key: JBMESSAGING-1689
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1689
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Security
>    Affects Versions: 1.4.0.SP3
>            Reporter: Colin Mondesir
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> The two trustStore parameters:
> org.jboss.remoting.trustStorePassword
> org.jboss.remoting.trustStore
> Are not currently passed by JBM to the remoting layer.

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

        

From jira-events at lists.jboss.org  Mon Jul 20 23:35:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 20 Jul 2009 23:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1690) Bridge does
 not use targetCffName property
In-Reply-To: <846953131.1248096269430.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <519659489.1248147329312.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1690:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> Bridge does not use targetCffName property
> ------------------------------------------
>
>                 Key: JBMESSAGING-1690
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1690
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.2.GA
>         Environment: n/a
>            Reporter: Lukasz Dywicki
>            Assignee: Tim Fox
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: targetCFF.diff
>
>
> Bridge does not use targetCffName property. It always will be overriden by conditions inside setupJMSObjects method. There is no way to set this value over JMX.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 20 23:37:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 20 Jul 2009 23:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1690) Bridge does
 not use targetCffName property
In-Reply-To: <846953131.1248096269430.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <564166620.1248147449234.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1690:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> Bridge does not use targetCffName property
> ------------------------------------------
>
>                 Key: JBMESSAGING-1690
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1690
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.2.GA
>         Environment: n/a
>            Reporter: Lukasz Dywicki
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: targetCFF.diff
>
>
> Bridge does not use targetCffName property. It always will be overriden by conditions inside setupJMSObjects method. There is no way to set this value over JMX.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 20 23:43:43 2009
From: jira-events at lists.jboss.org (Paul Smith (JIRA))
Date: Mon, 20 Jul 2009 23:43:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2214) Custom Work Items
 that have the same handler only triggers the first handler in the rule flow
Message-ID: <1102695238.1248147823835.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Custom Work Items that have the same handler only triggers the first handler in the rule flow
---------------------------------------------------------------------------------------------

                 Key: JBRULES-2214
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2214
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler (flow)
    Affects Versions: 5.0.1.FINAL
         Environment: Currently running under JDK 1.6 using Drools 5.0.1 Final
            Reporter: Paul Smith
            Assignee: Mark Proctor


I have created a simple rule flow that runs runs in a rule flow group. It then has two work item nodes that are both of the same type and are designed to simulate a parameterised database lookup. These two work items are named differently in the rule flow but have the same handler class. When I start the process, only the first work item is triggered, not the second one. I have attached a zip file with the eclipse workspace files for testing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 20 23:47:29 2009
From: jira-events at lists.jboss.org (Paul Smith (JIRA))
Date: Mon, 20 Jul 2009 23:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2214) Custom Work Items
 that have the same handler only triggers the first handler in the rule flow
In-Reply-To: <1102695238.1248147823835.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <7905251.1248148049186.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Smith updated JBRULES-2214:
--------------------------------

    Attachment: 2214.zip


Eclipse workspace containing test case

> Custom Work Items that have the same handler only triggers the first handler in the rule flow
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2214
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2214
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Currently running under JDK 1.6 using Drools 5.0.1 Final
>            Reporter: Paul Smith
>            Assignee: Mark Proctor
>         Attachments: 2214.zip
>
>
> I have created a simple rule flow that runs runs in a rule flow group. It then has two work item nodes that are both of the same type and are designed to simulate a parameterised database lookup. These two work items are named differently in the rule flow but have the same handler class. When I start the process, only the first work item is triggered, not the second one. I have attached a zip file with the eclipse workspace files for testing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 00:00:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 21 Jul 2009 00:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1690) Bridge does
 not use targetCffName property
In-Reply-To: <846953131.1248096269430.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <202594523.1248148829867.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476943#action_12476943 ] 

Howard Gao commented on JBMESSAGING-1690:
-----------------------------------------

Hi Lukasz,

This issue has been fixed in the latest release (1.4.4.GA). Can you verify it? Thanks.


Howard


> Bridge does not use targetCffName property
> ------------------------------------------
>
>                 Key: JBMESSAGING-1690
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1690
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.2.GA
>         Environment: n/a
>            Reporter: Lukasz Dywicki
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: targetCFF.diff
>
>
> Bridge does not use targetCffName property. It always will be overriden by conditions inside setupJMSObjects method. There is no way to set this value over JMX.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 00:18:29 2009
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 21 Jul 2009 00:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7110)
 ClusterPartition.ThreadGate can block shutdown of AS
In-Reply-To: <1909704028.1248121829865.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <745721289.1248149909278.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro resolved JBAS-7110.
--------------------------------

    Resolution: Done


Adapted new ThreadGate implementation from org.jboss.cache.util.concurrent.ReclosableLatch utilizing an AbstractQueuedSynchronizer.

> ClusterPartition.ThreadGate can block shutdown of AS
> ----------------------------------------------------
>
>                 Key: JBAS-7110
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7110
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The following stack trace appears in a thread dump, after a failure to shutdown the AS within the testsuite:
> Thread: JBoss Shutdown Hook : priority:5, demon:true, threadId:11, threadState:TIMED_WAITING
> - waiting on <0x1d7ada9> (a org.jboss.ha.framework.server.ClusterPartition$ThreadGate)
> java.lang.Object.wait(Native Method)
> org.jboss.ha.framework.server.ClusterPartition$ThreadGate.await(ClusterPartition.java:2381)
> org.jboss.ha.framework.server.ClusterPartition.callAsynchMethodOnCluster(ClusterPartition.java:1325)
> org.jboss.ha.framework.server.DistributedReplicantManagerImpl.remove(DistributedReplicantManagerImpl.java:448)
> org.jboss.profileservice.cluster.repository.DefaultRepositoryClusteringHandler.shutdown(DefaultRepositoryClusteringHandler.java:275)
> org.jboss.system.server.profileservice.repository.clustered.ClusteredDeploymentRepository.unload(ClusteredDeploymentRepository.java:459)
> org.jboss.system.server.profile.repository.AbstractProfile.destroy(AbstractProfile.java:163)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:97)
> org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:77)
> org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.uninstall(AbstractProfileLifeCycleAction.java:57)
> org.jboss.system.server.profileservice.repository.AbstractProfileAction.uninstall(AbstractProfileAction.java:70)
> org.jboss.system.server.profileservice.repository.AbstractProfileService.uninstall(AbstractProfileService.java:417)
> org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1665)
> org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1276)
> org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1180)
> org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1235)
> org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1180)
> org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1235)
> org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:828)
> org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> org.jboss.system.server.profileservice.repository.AbstractProfileService.deactivateProfile(AbstractProfileService.java:448)
> org.jboss.system.server.profileservice.ProfileServiceBootstrap.deactivateProfiles(ProfileServiceBootstrap.java:381)
> org.jboss.system.server.profileservice.ProfileServiceBootstrap.shutdown(ProfileServiceBootstrap.java:339)
> org.jboss.bootstrap.AbstractServerImpl.shutdownServer(AbstractServerImpl.java:571)
> org.jboss.bootstrap.AbstractServerImpl$ShutdownHook.run(AbstractServerImpl.java:909)
> The root cause is a bug in ThreadGate.await(long), which does not correctly return if the timeout value is reached while the gate is still closed.
> This same issue was found and fixed in JBC.  See JBCACHE-1173.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 00:38:41 2009
From: jira-events at lists.jboss.org (Paul Smith (JIRA))
Date: Tue, 21 Jul 2009 00:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2214) Custom Work Items
 that have the same handler only triggers the first handler in the rule flow
In-Reply-To: <1102695238.1248147823835.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1498613872.1248151121941.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Smith closed JBRULES-2214.
-------------------------------

    Resolution: Won't Fix


My appologies. This is invalid. I was not telling the WorkItemManager to complete the work item. Closing.

> Custom Work Items that have the same handler only triggers the first handler in the rule flow
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2214
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2214
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Currently running under JDK 1.6 using Drools 5.0.1 Final
>            Reporter: Paul Smith
>            Assignee: Mark Proctor
>         Attachments: 2214.zip
>
>
> I have created a simple rule flow that runs runs in a rule flow group. It then has two work item nodes that are both of the same type and are designed to simulate a parameterised database lookup. These two work items are named differently in the rule flow but have the same handler class. When I start the process, only the first work item is triggered, not the second one. I have attached a zip file with the eclipse workspace files for testing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 02:32:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 21 Jul 2009 02:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2055341109.1248157949241.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476953#action_12476953 ] 

Howard Gao commented on JBMESSAGING-1685:
-----------------------------------------

Hi Martin, 

I created a simple test program where 2000 session.rollback() are performed. It runs without any problem. I'll upload it and can you have a look please?

I tried with JBOSS 5.1.0.GA/jbm 1.4.3 as well as JBoss 4.2.3.GA / jbm 1.4.4.GA

Thanks.
Howard


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 02:34:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 21 Jul 2009 02:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2134544278.1248158069221.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1685:
------------------------------------

    Attachment: QueueExample.java


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 02:52:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Jul 2009 02:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1012) TP: fetch physical
 address associated with logical address more quickly
In-Reply-To: <547183200.1247820389194.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1552585429.1248159149163.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1012.
----------------------------

    Resolution: Done


AgeOutCache is now used to keep a list of logical addresses for which discovery requests were sent. They get kicked out of the cache after 5 secs, so each request for a given logical address is not sent more than once in 5 secs

> TP: fetch physical address associated with logical address more quickly
> -----------------------------------------------------------------------
>
>                 Key: JGRP-1012
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1012
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> Currently, when we send a unicast message and don't have the physical address available, we send a discovery request for the physical address and trash the message.
> Later, when the physical address has been received and added to the transport's cache, the retransmission of the unicast message will succeed.
> In order not to generate too much traffic, we send such a discovery request only every 5 seconds (hard-coded) max. However, this is for *all* addresses. So if we have physical addresses for P, Q and R missing, the total time to send the 3 discovery requests will be 15 sec max ! So we would not be able to send a unicast to R for up to 15 secs !
> This is bad, we should keep track of *which* addresses we've sent out discovery requests for, and have timeouts based on individual addresses, for example in the form of a cache (keys=addrs, values=last time sent).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 06:43:30 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 21 Jul 2009 06:43:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1689) Pass
 trustStore parameters to remoting layer
In-Reply-To: <369523920.1248073853274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1651219180.1248173010023.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476981#action_12476981 ] 

Howard Gao commented on JBMESSAGING-1689:
-----------------------------------------

To use these two parameters, we need to pass those properties in constructing Client with its constructor Client(locator, config). 
There are two places in JBM code base where remoting client are created. One is JMSRemotingConnection.start(), the other is ClientConnectionFactoryDelegate.createClient(). We can use the following code to pass the parameters in both places:
      
      String trustStoreLoc = System.getProperty("org.jboss.remoting.trustStore");
      if (trustStoreLoc != null)
      {
         configuration.put("org.jboss.remoting.trustStore", trustStoreLoc);
         String trustStorePassword = System.getProperty("org.jboss.remoting.trustStorePassword");
         if (trustStorePassword != null)
         {
            configuration.put("org.jboss.remoting.trustStorePassword", trustStorePassword);
         }
      }


> Pass trustStore parameters to remoting layer
> --------------------------------------------
>
>                 Key: JBMESSAGING-1689
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1689
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Security
>    Affects Versions: 1.4.0.SP3
>            Reporter: Colin Mondesir
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> The two trustStore parameters:
> org.jboss.remoting.trustStorePassword
> org.jboss.remoting.trustStore
> Are not currently passed by JBM to the remoting layer.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 08:12:29 2009
From: jira-events at lists.jboss.org (Alexandre Navarro (JIRA))
Date: Tue, 21 Jul 2009 08:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-364) Differentiate a human
 task from a programmatic task (java,
 sql ... or state) in the editor as you do between a decision and a task
Message-ID: <1334668197.1248178349410.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Differentiate a human task  from a programmatic task (java, sql ... or state) in the editor as you do between a decision and a task
-----------------------------------------------------------------------------------------------------------------------------------

                 Key: GPD-364
                 URL: https://jira.jboss.org/jira/browse/GPD-364
             Project: JBoss jBPM GPD
          Issue Type: Feature Request
    Affects Versions: jBPM jPDL Designer 4.0.0.GA
            Reporter: Alexandre Navarro
            Assignee: Koen Aers


Differentiate a human task  from a programmatic task (java, sql ... or state) in the editor as you do between a decision and a task

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 08:26:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 21 Jul 2009 08:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7113) Wrong address in
	probe.sh
Message-ID: <374438215.1248179189358.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Wrong address in probe.sh
-------------------------

                 Key: JBAS-7113
                 URL: https://jira.jboss.org/jira/browse/JBAS-7113
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


Bela Ban wrote:
> (probe.sh) uses the wrong port 224.0.0.75 instead of 224.0.75.75. This needs to be 
> changed, either by upgrading jgroups.jar or by adding "
> 
> -addr 224.0.75.75 $*"
> 
> to jboss-5.1.0.GA/bin/probe.sh
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 08:41:29 2009
From: jira-events at lists.jboss.org (Martin Gekeler (JIRA))
Date: Tue, 21 Jul 2009 08:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7059) Compatibility issue
 JBoss-5.1.0.GA -> JBoss-5.0.0.GA
In-Reply-To: <6442969.1246020777740.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <650086546.1248180089572.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gekeler resolved JBAS-7059.
----------------------------------

    Fix Version/s: JBossAS-5.1.0.GA
       Resolution: Won't Fix


The JBoss client classes in 5.0.0.GA are incompatible with JBoss client classes in 5.1.0.GA. 
Solution: Update client classes. 

> Compatibility issue JBoss-5.1.0.GA -> JBoss-5.0.0.GA 
> -----------------------------------------------------
>
>                 Key: JBAS-7059
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7059
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: JBoss-5.1.0.GA, Windows, local PC. 
>            Reporter: Martin Gekeler
>             Fix For: JBossAS-5.1.0.GA
>
>
> java.lang.ClassCastException: javax.naming.Reference cannot be cast to com.sdt.pellworm.ejb.Pellworm
> 	at com.sdt.pellworm.test.junit.TestPellwormEJB.testSayHello(TestPellwormEJB.java:29)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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:168)
> 	at junit.framework.TestCase.runBare(TestCase.java:134)
> 	at junit.framework.TestResult$1.protect(TestResult.java:110)
> 	at junit.framework.TestResult.runProtected(TestResult.java:128)
> 	at junit.framework.TestResult.run(TestResult.java:113)
> 	at junit.framework.TestCase.run(TestCase.java:124)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:232)
> 	at junit.framework.TestSuite.run(TestSuite.java:227)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:232)
> 	at junit.framework.TestSuite.run(TestSuite.java:227)
> 	at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:76)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
> 	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)
> When i call the test case below from within eclipse I get this exception with JBoss-5.1.0.GA. 
> I do not get it with JBoss-5.0.0.GA. 
> Here's the code: 
> public class TestPellwormEJB extends TestCase {
> public void testSayHello() {
>       InitialContext  ctx    = null; 
>       Pellworm tsBean = null; 
>       TestUtils.echoLogHello(this.getClass().getSimpleName(), this.getName()); 
>       try {
>          ctx    = new InitialContext(TestUtils.createInitialContext());
>       } catch (NamingException e) {
>          fail(e.getMessage()); 
>       }
>       try {
>          // tsBean = (Pellworm) ctx.lookup("PellwormBean/remote");
>          Object object = ctx.lookup("PellwormBean/remote");
>          tsBean = (Pellworm) object; 
>       } catch (NamingException e) {
>          fail(e.getMessage()); 
>       }
>                   
>       try {
>          assertEquals("Hallo! Ich bin Pellworm. ", tsBean.sayHello());
>       } catch (RemoteException e) {
>          fail(e.getMessage()); 
>       }
>    }
>    
> }  
> I haven't found a compatiblity issue in the release notes about this. 
> Cheers, 
> -M.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 08:43:29 2009
From: jira-events at lists.jboss.org (Martin Gekeler (JIRA))
Date: Tue, 21 Jul 2009 08:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7059) Compatibility issue
 JBoss-5.1.0.GA -> JBoss-5.0.0.GA
In-Reply-To: <6442969.1246020777740.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1158953747.1248180209249.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gekeler closed JBAS-7059.
--------------------------------



> Compatibility issue JBoss-5.1.0.GA -> JBoss-5.0.0.GA 
> -----------------------------------------------------
>
>                 Key: JBAS-7059
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7059
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: JBoss-5.1.0.GA, Windows, local PC. 
>            Reporter: Martin Gekeler
>             Fix For: JBossAS-5.1.0.GA
>
>
> java.lang.ClassCastException: javax.naming.Reference cannot be cast to com.sdt.pellworm.ejb.Pellworm
> 	at com.sdt.pellworm.test.junit.TestPellwormEJB.testSayHello(TestPellwormEJB.java:29)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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:168)
> 	at junit.framework.TestCase.runBare(TestCase.java:134)
> 	at junit.framework.TestResult$1.protect(TestResult.java:110)
> 	at junit.framework.TestResult.runProtected(TestResult.java:128)
> 	at junit.framework.TestResult.run(TestResult.java:113)
> 	at junit.framework.TestCase.run(TestCase.java:124)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:232)
> 	at junit.framework.TestSuite.run(TestSuite.java:227)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:232)
> 	at junit.framework.TestSuite.run(TestSuite.java:227)
> 	at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:76)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
> 	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)
> When i call the test case below from within eclipse I get this exception with JBoss-5.1.0.GA. 
> I do not get it with JBoss-5.0.0.GA. 
> Here's the code: 
> public class TestPellwormEJB extends TestCase {
> public void testSayHello() {
>       InitialContext  ctx    = null; 
>       Pellworm tsBean = null; 
>       TestUtils.echoLogHello(this.getClass().getSimpleName(), this.getName()); 
>       try {
>          ctx    = new InitialContext(TestUtils.createInitialContext());
>       } catch (NamingException e) {
>          fail(e.getMessage()); 
>       }
>       try {
>          // tsBean = (Pellworm) ctx.lookup("PellwormBean/remote");
>          Object object = ctx.lookup("PellwormBean/remote");
>          tsBean = (Pellworm) object; 
>       } catch (NamingException e) {
>          fail(e.getMessage()); 
>       }
>                   
>       try {
>          assertEquals("Hallo! Ich bin Pellworm. ", tsBean.sayHello());
>       } catch (RemoteException e) {
>          fail(e.getMessage()); 
>       }
>    }
>    
> }  
> I haven't found a compatiblity issue in the release notes about this. 
> Cheers, 
> -M.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 09:30:29 2009
From: jira-events at lists.jboss.org (Garry Wright (JIRA))
Date: Tue, 21 Jul 2009 09:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1870) stopDelivery
 on active MDB results in exception (Session not found)
In-Reply-To: <830057413.1248107189559.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1492225769.1248183029901.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477007#action_12477007 ] 

Garry Wright commented on EJBTHREE-1870:
----------------------------------------

Particularly interested in a fix for this as we use stopDelivery extensively in production to stop MDB consumption on other "instances" of the same MDB and or related components in the event of particular  exceptions. 

> stopDelivery on active MDB results in exception (Session not found)
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1870
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1870
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: ejb3
>    Affects Versions: 1.1.3
>         Environment: Mac OS/X Leopard, JDK 6, JBoss 5.1.0GA
>            Reporter: Philip Dodds
>         Attachments: stopdelivery-mdb.zip
>
>
> If you start an MDB and introduce a messages to it then use the stopDelivery method of the MDB's MBean to stop it consuming messages you get an exception.  Note this problem only occurs if the MDB has a transaction in flight when the stopDelivery is called.
> 2009-05-20 12:30:52,499 ERROR [org.jboss.messaging.util.ExceptionUtil] (WorkManager(2)-44) Connectio
> nEndpoint[fe-oz919yuf-1-mj809yuf-bruz48-x21o4c5] sendTransaction [ur4-b6b39yuf-1-mj809yuf-bruz48-x21
> o4c5]
> javax.jms.IllegalStateException: Cannot find session with id ie-qz919yuf-1-mj809yuf-bruz48-x21o4c5
> 	at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.processTransaction(ServerConnectionEndpoi
> nt.java:835)
> 	at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.
> java:497)
> 	at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$Co
> nnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:101)
> 	at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.inv
> okeTarget(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
> I have attached a slightly doctors version of the EJB3 MDB example code,  it has been changed to introduce a sleep of 5 seconds in the MDB (to keep the transaction active longer) and also introduces a higher volume of messages to give you a chance to get to the JMX console and call stopDelivery.  If you don't get an exception on the first attempt it is worth trying again as the transaction must be in flight for the problem to occur.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 09:39:29 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Tue, 21 Jul 2009 09:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7114) Undeploy-deploy loop
 of directly referenced applications due to hasStructureBeenModified
Message-ID: <1522448733.1248183569203.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Undeploy-deploy loop of directly referenced applications due to hasStructureBeenModified
----------------------------------------------------------------------------------------

                 Key: JBAS-7114
                 URL: https://jira.jboss.org/jira/browse/JBAS-7114
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: VFS
    Affects Versions: JBossAS-5.1.0.GA
         Environment: 14:51:33,954 INFO  [ServerInfo] Java version: 1.6.0_14,Sun Microsystems Inc.
14:51:33,954 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
14:51:33,954 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 14.0-b16,Sun Microsystems Inc.
14:51:33,954 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
14:51:33,955 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Dcom.sun.management.jmxremote -Xms128m -Xmx1536m -XX:MaxPermSize=256m -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 

            Reporter: Juergen none
            Assignee: Ales Justin


in conf/bootstrap/profile.xml, applicationURIs:
<value>file://home/login-service.sar</value>
<value>file://home/app-local.ear</value>

login-service.sar gets undeployed-redeployed every 5000 ms (HDScanner interval)

from debugging:
org.jboss.system.server.profileservice.repository.HotDeploymentRepository.getModifiedDeployments(), calling hasStructureBeenModified()
for file://home/jboss-login-edirectory-service.sar stays true

both files share same root.getPathName() == "" !
org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker.hasRootBeenModified():
1) root := app-local.ear: (app-local.ear).getPathName() == "", cached value for "" is null, put lastModified of (app-local.ear).getLastModified()
2) root := login-service.sar: (login-service.sar).getPathName() == "", cache value for "" is (app-local.ear).getLastModified() (<= (login-service.sar).getLastModified()) -> redeploy login-service.sar + getCache().invalidateCache(root.getPathName()): set "" to null
3) back to 1) -> loop

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 09:39:29 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Tue, 21 Jul 2009 09:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7114) Undeploy-deploy loop
 of directly referenced applications due to hasStructureBeenModified
In-Reply-To: <1522448733.1248183569203.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <775943110.1248183569305.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juergen none updated JBAS-7114:
-------------------------------

    Description: 
in conf/bootstrap/profile.xml, applicationURIs:
<value>file://home/login-service.sar</value>
<value>file://home/app-local.ear</value>

login-service.sar gets undeployed-redeployed every 5000 ms (HDScanner interval)

from debugging:
org.jboss.system.server.profileservice.repository.HotDeploymentRepository.getModifiedDeployments(), calling hasStructureBeenModified()
for file://home/login-service.sar stays true

both files share same root.getPathName() == "" !
org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker.hasRootBeenModified():
1) root := app-local.ear: (app-local.ear).getPathName() == "", cached value for "" is null, put lastModified of (app-local.ear).getLastModified()
2) root := login-service.sar: (login-service.sar).getPathName() == "", cache value for "" is (app-local.ear).getLastModified() (<= (login-service.sar).getLastModified()) -> redeploy login-service.sar + getCache().invalidateCache(root.getPathName()): set "" to null
3) back to 1) -> loop

  was:
in conf/bootstrap/profile.xml, applicationURIs:
<value>file://home/login-service.sar</value>
<value>file://home/app-local.ear</value>

login-service.sar gets undeployed-redeployed every 5000 ms (HDScanner interval)

from debugging:
org.jboss.system.server.profileservice.repository.HotDeploymentRepository.getModifiedDeployments(), calling hasStructureBeenModified()
for file://home/jboss-login-edirectory-service.sar stays true

both files share same root.getPathName() == "" !
org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker.hasRootBeenModified():
1) root := app-local.ear: (app-local.ear).getPathName() == "", cached value for "" is null, put lastModified of (app-local.ear).getLastModified()
2) root := login-service.sar: (login-service.sar).getPathName() == "", cache value for "" is (app-local.ear).getLastModified() (<= (login-service.sar).getLastModified()) -> redeploy login-service.sar + getCache().invalidateCache(root.getPathName()): set "" to null
3) back to 1) -> loop



> Undeploy-deploy loop of directly referenced applications due to hasStructureBeenModified
> ----------------------------------------------------------------------------------------
>
>                 Key: JBAS-7114
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7114
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: VFS
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: 14:51:33,954 INFO  [ServerInfo] Java version: 1.6.0_14,Sun Microsystems Inc.
> 14:51:33,954 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
> 14:51:33,954 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 14.0-b16,Sun Microsystems Inc.
> 14:51:33,954 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 14:51:33,955 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Dcom.sun.management.jmxremote -Xms128m -Xmx1536m -XX:MaxPermSize=256m -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
>            Reporter: Juergen none
>            Assignee: Ales Justin
>
> in conf/bootstrap/profile.xml, applicationURIs:
> <value>file://home/login-service.sar</value>
> <value>file://home/app-local.ear</value>
> login-service.sar gets undeployed-redeployed every 5000 ms (HDScanner interval)
> from debugging:
> org.jboss.system.server.profileservice.repository.HotDeploymentRepository.getModifiedDeployments(), calling hasStructureBeenModified()
> for file://home/login-service.sar stays true
> both files share same root.getPathName() == "" !
> org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker.hasRootBeenModified():
> 1) root := app-local.ear: (app-local.ear).getPathName() == "", cached value for "" is null, put lastModified of (app-local.ear).getLastModified()
> 2) root := login-service.sar: (login-service.sar).getPathName() == "", cache value for "" is (app-local.ear).getLastModified() (<= (login-service.sar).getLastModified()) -> redeploy login-service.sar + getCache().invalidateCache(root.getPathName()): set "" to null
> 3) back to 1) -> loop

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 09:51:29 2009
From: jira-events at lists.jboss.org (Michael Harvey (JIRA))
Date: Tue, 21 Jul 2009 09:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1276) Run
 Performance Tests on Cluster with JBM and JBoss 5 (testing the shared
 transports)
In-Reply-To: <32566632.1208188075391.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1682913147.1248184289456.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Harvey reassigned JBMESSAGING-1276:
-------------------------------------------

    Assignee: Rajesh Rajasekaran  (was: Phillip Thurmond)


I did not see Pavel in the "Assignee" list

> Run Performance Tests on Cluster with JBM and JBoss 5 (testing the shared transports)
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1276
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1276
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: AS Integration
>            Reporter: Clebert Suconic
>            Assignee: Rajesh Rajasekaran
>             Fix For: Unscheduled
>
>
> As requested by Bela, we should run some performance tests using their new Shared Channels on JGroups 2.6.2 (on JBoss 5)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 09:53:29 2009
From: jira-events at lists.jboss.org (Tej jbpm (JIRA))
Date: Tue, 21 Jul 2009 09:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-365) taskInstance.id not
 accessible in jbpm.mail.templates for custom template
Message-ID: <2017380803.1248184409290.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

taskInstance.id not accessible in jbpm.mail.templates for custom template
-------------------------------------------------------------------------

                 Key: GPD-365
                 URL: https://jira.jboss.org/jira/browse/GPD-365
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM jPDL Designer 3.2
         Environment: Windows Vista, Eclipse 3.4.2, JBPM 3.2.1
            Reporter: Tej jbpm
            Assignee: Koen Aers


Hi 

JSF Expresssion {taskInstance.id} works in the "task-assign" and "task-reminder" mail templates. But when i create a custom template {taskInstance.id} does not return anything.

Whatever variables accessible by default templates should be accessible by custom mail templates as well. 

Thanks

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 10:56:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 21 Jul 2009 10:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1689) Pass
 trustStore parameters to remoting layer
In-Reply-To: <369523920.1248073853274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <427670994.1248188189341.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1689.
-----------------------------------

    Resolution: Done


Done. The secure-socket example has changed to use these parameters to show it works.

> Pass trustStore parameters to remoting layer
> --------------------------------------------
>
>                 Key: JBMESSAGING-1689
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1689
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Security
>    Affects Versions: 1.4.0.SP3
>            Reporter: Colin Mondesir
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> The two trustStore parameters:
> org.jboss.remoting.trustStorePassword
> org.jboss.remoting.trustStore
> Are not currently passed by JBM to the remoting layer.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 11:32:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 21 Jul 2009 11:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1496) Complete large
 message copying
In-Reply-To: <22649485.1233606644293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <986915061.1248190349170.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1496.
----------------------------------------

    Resolution: Done


> Complete large message copying
> ------------------------------
>
>                 Key: JBMESSAGING-1496
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1496
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Improve large message copying, by creating link on file system.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 11:37:29 2009
From: jira-events at lists.jboss.org (Martin Malina (JIRA))
Date: Tue, 21 Jul 2009 11:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1859210009.1248190649586.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477026#action_12477026 ] 

Martin Malina commented on JBAS-7049:
-------------------------------------

Is there any way we can fix this issue with a workaround or do we have to wait if a backport fix makes it into OpenJDK6? So far there is no update on the Bugzilla.

> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 11:43:29 2009
From: jira-events at lists.jboss.org (Martin Malina (JIRA))
Date: Tue, 21 Jul 2009 11:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6966) Some tests fail
 with IBM JDK - java.lang.IllegalArgumentException: SSLv2Hello
In-Reply-To: <28786754.1242998527053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1671591278.1248191009220.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477028#action_12477028 ] 

Martin Malina commented on JBAS-6966:
-------------------------------------

Anil, how can we deprecate it? We were trying to do it with the other JIRA [1] but we didn't find a way to do it then.
If we cannot fix this, we will have to document it as a known issue.

[1] JBPAPP-626

> Some tests fail with IBM JDK - java.lang.IllegalArgumentException: SSLv2Hello
> -----------------------------------------------------------------------------
>
>                 Key: JBAS-6966
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6966
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: SSLv2Hello-error
>
>
> Some tests in the testsuite are failing due to IBM JDK not supporting the SSLv2Hello protocol:
> 15:10:46,727 ERROR [AbstractKernelController] Error installing to Start: name=jboss:service=invoker,socketType=SSLSocketFactory,type=jrmp,wantsClientAuth=true state=Create mode=Manual requiredState=Installed
> java.lang.IllegalArgumentException: SSLv2Hello
> 	at com.ibm.jsse2.mb.a(mb.java:24)
> 	at com.ibm.jsse2.lb.<init>(lb.java:41)
> 	at com.ibm.jsse2.hc.setEnabledProtocols(hc.java:57)
> 	at org.jboss.security.ssl.DomainServerSocketFactory.createServerSocket(DomainServerSocketFactory.java:267)
> 	at org.jboss.security.ssl.DomainServerSocketFactory.createServerSocket(DomainServerSocketFactory.java:226)
> 	at org.jboss.security.ssl.RMISSLServerSocketFactory.createServerSocket(RMISSLServerSocketFactory.java:120)
> 	at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:638)
> 	at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:272)
> 	at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:219)
> 	at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:398)
> ...
> This problem was previously reported as JBPAPP-626 but never fixed. I'm creating a new JIRA since it now affects more testcases.
> These testcases fail:
> org.jboss.test.jrmp.test.CustomSocketsUnitTestCase
> org.jboss.test.jrmp.test.SSLFailuresSocketsUnitTestCase
> org.jboss.test.jrmp.test.SSLSocketsUnitTestCase
> org.jboss.test.pooled.test.SSLSocketsUnitTestCase
> We can still leave it as it is - meaning documenting these failures as known issues with IBM JDK. I just wanted to make sure we know about it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 11:45:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 21 Jul 2009 11:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <567381131.1248191129471.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477029#action_12477029 ] 

Anil Saldhana commented on JBAS-7049:
-------------------------------------

The workaround is to comment out the "java.security.debug" statement in imports/server-config.xml

> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 11:45:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 21 Jul 2009 11:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1409915708.1248191129680.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBAS-7049:
--------------------------------

    Workaround Description: Comment out the "java.security.debug" statement in imports/server-config.xml of testsuite, until the OpenJDK6 bug is fixed.
                Workaround: [Workaround Exists]


> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 11:53:29 2009
From: jira-events at lists.jboss.org (Martin Malina (JIRA))
Date: Tue, 21 Jul 2009 11:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1031842455.1248191609378.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477032#action_12477032 ] 

Martin Malina commented on JBAS-7049:
-------------------------------------

OK, thanks. If I understand it correctly it only affects the level of logging so it shouldn't cause any regressions. Just to make sure I will try to change it and then run the test suite tomorrow. If it's OK, we can go ahead and commit it.

> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 11:56:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 21 Jul 2009 11:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1595756589.1248191789381.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477033#action_12477033 ] 

Anil Saldhana commented on JBAS-7049:
-------------------------------------

Not possible to just change it for the OpenJDK issue?  We want the debug to be on to see if there are issues on other platforms.

> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 11:22:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 11:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-142) SP Post Form
 Authenticator that can handle signatures
Message-ID: <356609847.1248362549083.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SP Post Form Authenticator that can handle signatures
-----------------------------------------------------

                 Key: JBID-142
                 URL: https://jira.jboss.org/jira/browse/JBID-142
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1


Currently we do not have a form authenticator doing POST on the SP end that can handle signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 10:34:44 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Thu, 23 Jul 2009 10:34:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-21) make
 org.jboss.logging.filter.TCLFilter.isMatchingTCL() non-private for
 overriding purposes
Message-ID: <542988471.1248359684786.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

make org.jboss.logging.filter.TCLFilter.isMatchingTCL() non-private for overriding purposes
-------------------------------------------------------------------------------------------

                 Key: JBLOGGING-21
                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-21
             Project: JBoss Logging
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: jboss-logging-log4j
    Affects Versions: 2.1.0.GA-log4j
         Environment: jboss-5.1.0.GA
            Reporter: Juergen none
            Assignee: Dimitris Andreadis
         Attachments: RegExpTCLFilter.java

I wanted to override TCLFilter to implement a RegExpTCLFilter, but because org.jboss.logging.filter.TCLFilter.isMatchingTCL() is declared private I could not subclass TCLFilter and just override that method.

might be nice to change from private to protected

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 10:14:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 23 Jul 2009 10:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-535) Move task
 configuration in server-config.xml into a target
In-Reply-To: <1701874410.1247777909261.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <140682512.1248358469128.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier reassigned JBBUILD-535:
---------------------------------

    Assignee: Paul Gier


> Move task configuration in server-config.xml into a target
> ----------------------------------------------------------
>
>                 Key: JBBUILD-535
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-535
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the task definitions in server-config.xml are not inside a target.  This means that they can't depend on another target to define their path references.  This should be changed so that everything is done inside targets.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 10:34:44 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Thu, 23 Jul 2009 10:34:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBLOGGING-21) make
 org.jboss.logging.filter.TCLFilter.isMatchingTCL() non-private for
 overriding purposes
In-Reply-To: <542988471.1248359684786.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1910849914.1248359684946.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juergen none updated JBLOGGING-21:
----------------------------------

    Attachment: RegExpTCLFilter.java


> make org.jboss.logging.filter.TCLFilter.isMatchingTCL() non-private for overriding purposes
> -------------------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-21
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-21
>             Project: JBoss Logging
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-log4j
>    Affects Versions: 2.1.0.GA-log4j
>         Environment: jboss-5.1.0.GA
>            Reporter: Juergen none
>            Assignee: Dimitris Andreadis
>         Attachments: RegExpTCLFilter.java
>
>
> I wanted to override TCLFilter to implement a RegExpTCLFilter, but because org.jboss.logging.filter.TCLFilter.isMatchingTCL() is declared private I could not subclass TCLFilter and just override that method.
> might be nice to change from private to protected

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 10:18:29 2009
From: jira-events at lists.jboss.org (Martin Malina (JIRA))
Date: Thu, 23 Jul 2009 10:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6936) Testsuite fails
 during tests-profileservice target with IBM JDK 1.6 - AS instance not
 shutdown
In-Reply-To: <368622.1242662765255.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1668018397.1248358709191.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477294#action_12477294 ] 

Martin Malina commented on JBAS-6936:
-------------------------------------

I am still mainly operating with JBoss AS 5.1.0 GA so there the problem was obviously present.
I just saw the profileservice.excludes definition in build.xml and I was just wondering what it was for since I didn't see it used anywhere.
Anyway, with your commit it is taken care of.

> Testsuite fails during tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6936
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6936
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: threadDump.html
>
>
> The AS fails to start for the second time during the tests-profileservice target of the testsuite. This is caused by the first instance not being properly shutdown by the following ant command: <server:stop name="profileservice"/>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 11:36:29 2009
From: jira-events at lists.jboss.org (Sanne Grinovero (JIRA))
Date: Thu, 23 Jul 2009 11:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1876) CNFE on loading
 business interface of succesfully injected MBean in a quartz activated MDB
Message-ID: <461308215.1248363389242.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CNFE on loading business interface of succesfully injected MBean in a quartz activated MDB
------------------------------------------------------------------------------------------

                 Key: EJBTHREE-1876
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1876
             Project: EJB 3.0
          Issue Type: Bug
         Environment: JBoss 5.1.0.GA, JDK Java version: 1.6.0_14,Sun Microsystems Inc., Fedora 11-64bit
            Reporter: Sanne Grinovero


Getting a classnotfound exception when trying to use a reference to a MBean, injected by annotations.
Both MBean and the timer triggered MDB deploy correctly, also injection is working (something? is injected): the value of the reference is not null; as soon
as a method is called on the injected object CNFE happens on the interface being the type of the reference itself.

Please refer to the forum post for more details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 11:40:41 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 23 Jul 2009 11:40:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1876) CNFE on loading
 business interface of succesfully injected MBean in a quartz activated MDB
In-Reply-To: <461308215.1248363389242.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1334232622.1248363641901.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger reassigned EJBTHREE-1876:
---------------------------------------------

    Assignee: Andrew Lee Rubinger


> CNFE on loading business interface of succesfully injected MBean in a quartz activated MDB
> ------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1876
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1876
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: JBoss 5.1.0.GA, JDK Java version: 1.6.0_14,Sun Microsystems Inc., Fedora 11-64bit
>            Reporter: Sanne Grinovero
>            Assignee: Andrew Lee Rubinger
>
> Getting a classnotfound exception when trying to use a reference to a MBean, injected by annotations.
> Both MBean and the timer triggered MDB deploy correctly, also injection is working (something? is injected): the value of the reference is not null; as soon
> as a method is called on the injected object CNFE happens on the interface being the type of the reference itself.
> Please refer to the forum post for more details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 04:22:49 2009
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Thu, 23 Jul 2009 04:22:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-753) Distribute ant
 with the distro
In-Reply-To: <31300965.1169039633086.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <71304275.1248337369554.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Galder Zamarreno closed JBMESSAGING-753.
----------------------------------------

    Resolution: Out of Date


> Distribute ant with the distro
> ------------------------------
>
>                 Key: JBMESSAGING-753
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-753
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Build System
>            Reporter: Galder Zamarreno
>            Assignee: Tim Fox
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> Add to source and make messaging add it to the binary distribution 
> under util directory. That should speed up patching AS for customers 
> and would guarantee that they use the Ant version that we want them to use.
> This is currently implemented in JBC and JGroups and I find it very useful.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 04:30:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 23 Jul 2009 04:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-753) Distribute
 ant with the distro
In-Reply-To: <31300965.1169039633086.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1676437172.1248337829836.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox reopened JBMESSAGING-753:
---------------------------------



Galder- not sure why you closed this.

This _is_ something we want to do for JBM 2.0

> Distribute ant with the distro
> ------------------------------
>
>                 Key: JBMESSAGING-753
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-753
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Build System
>            Reporter: Galder Zamarreno
>            Assignee: Tim Fox
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> Add to source and make messaging add it to the binary distribution 
> under util directory. That should speed up patching AS for customers 
> and would guarantee that they use the Ant version that we want them to use.
> This is currently implemented in JBC and JGroups and I find it very useful.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 04:35:29 2009
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Thu, 23 Jul 2009 04:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-753) Distribute
 ant with the distro
In-Reply-To: <31300965.1169039633086.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <104741321.1248338129235.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477276#action_12477276 ] 

Galder Zamarreno commented on JBMESSAGING-753:
----------------------------------------------

Hmmm, Jeff Mesnil sent me an email saying:

"Hi Galder,

We're preparing the release of JBoss Messaging and there is this old issue you reported.
Is it still a concern for you? If it is, I'll fix it for JBM 2.0 otherwise, can you close it?

thanks,
jeff

-- 
Jeff Mesnil <jmesnil at redhat.com>
Core Developer (JBoss Messaging)
JBoss by Red Hat"

It's not a concern for me any more, hence I closed it :)

Maybe Jeff should talk to you instead? :)

> Distribute ant with the distro
> ------------------------------
>
>                 Key: JBMESSAGING-753
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-753
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Build System
>            Reporter: Galder Zamarreno
>            Assignee: Tim Fox
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> Add to source and make messaging add it to the binary distribution 
> under util directory. That should speed up patching AS for customers 
> and would guarantee that they use the Ant version that we want them to use.
> This is currently implemented in JBC and JGroups and I find it very useful.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 00:06:29 2009
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Thu, 23 Jul 2009 00:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBSER-116) Support
 deserialization generics objects
In-Reply-To: <2060572682.1248321029368.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1729539596.1248321989161.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBSER-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Takayoshi Kimura resolved JBSER-116.
------------------------------------

    Resolution: Rejected


It's not relevant to generics. The TestObject is missing default constructor.

> Support deserialization generics objects
> ----------------------------------------
>
>                 Key: JBSER-116
>                 URL: https://jira.jboss.org/jira/browse/JBSER-116
>             Project: JBoss Serialization
>          Issue Type: Feature Request
>    Affects Versions: 1.0.3 GA
>            Reporter: Takayoshi Kimura
>            Assignee: Clebert Suconic
>         Attachments: GenericsTestCase.patch
>
>
> Currently it seems JBoss Serialization doesn't support deserialization objects which contain a class using generics.
> org.jboss.serial.exception.SerializationException: Could not create instance of org.jboss.serial.generics.GenericsTestCase$TestObject - org.jboss.serial.generics.GenericsTestCase$TestObject
> 	at org.jboss.serial.classmetamodel.ClassMetaData.newInstance(ClassMetaData.java:354)
> 	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:219)
> 	at org.jboss.serial.objectmetamodel.DefaultObjectDescriptorStrategy.readObject(DefaultObjectDescriptorStrategy.java:160)
> 	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:264)
> 	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescriptionInternal(ObjectDescriptorFactory.java:82)
> 	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:53)
> 	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:725)
> 	at org.jboss.serial.io.JBossObjectInputStream.readObjectOverride(JBossObjectInputStream.java:211)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
> 	at org.jboss.serial.generics.GenericsTestCase.testGenerics(GenericsTestCase.java:56)
> Caused by: java.lang.InstantiationException: org.jboss.serial.generics.GenericsTestCase$TestObject
> 	at java.lang.Class.newInstance0(Class.java:335)
> 	at java.lang.Class.newInstance(Class.java:303)
> 	at org.jboss.serial.classmetamodel.ClassMetaData.newInstance(ClassMetaData.java:346)
> 	... 24 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 23:50:29 2009
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Wed, 22 Jul 2009 23:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSER-116) Support
 deserialization generics objects
In-Reply-To: <2060572682.1248321029368.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <767849946.1248321029545.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBSER-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Takayoshi Kimura updated JBSER-116:
-----------------------------------

    Attachment: GenericsTestCase.patch


> Support deserialization generics objects
> ----------------------------------------
>
>                 Key: JBSER-116
>                 URL: https://jira.jboss.org/jira/browse/JBSER-116
>             Project: JBoss Serialization
>          Issue Type: Feature Request
>    Affects Versions: 1.0.3 GA
>            Reporter: Takayoshi Kimura
>            Assignee: Clebert Suconic
>         Attachments: GenericsTestCase.patch
>
>
> Currently it seems JBoss Serialization doesn't support deserialization objects which contain a class using generics.
> org.jboss.serial.exception.SerializationException: Could not create instance of org.jboss.serial.generics.GenericsTestCase$TestObject - org.jboss.serial.generics.GenericsTestCase$TestObject
> 	at org.jboss.serial.classmetamodel.ClassMetaData.newInstance(ClassMetaData.java:354)
> 	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:219)
> 	at org.jboss.serial.objectmetamodel.DefaultObjectDescriptorStrategy.readObject(DefaultObjectDescriptorStrategy.java:160)
> 	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:264)
> 	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescriptionInternal(ObjectDescriptorFactory.java:82)
> 	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:53)
> 	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:725)
> 	at org.jboss.serial.io.JBossObjectInputStream.readObjectOverride(JBossObjectInputStream.java:211)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
> 	at org.jboss.serial.generics.GenericsTestCase.testGenerics(GenericsTestCase.java:56)
> Caused by: java.lang.InstantiationException: org.jboss.serial.generics.GenericsTestCase$TestObject
> 	at java.lang.Class.newInstance0(Class.java:335)
> 	at java.lang.Class.newInstance(Class.java:303)
> 	at org.jboss.serial.classmetamodel.ClassMetaData.newInstance(ClassMetaData.java:346)
> 	... 24 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 23:41:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 22 Jul 2009 23:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1586938086.1248320489153.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477267#action_12477267 ] 

Howard Gao commented on JBMESSAGING-1664:
-----------------------------------------

Currently I think I have two options.

Option 1 is based on my current fix. To limit the memory when we fetch all the messages for a queue from DB, we can use Statement.setFetchSize().

Option 2 is that we split the query into two queries. First we query up to fullSize the messages for a Channel (queue), of which we can safely put those messages whose PAGE_ORD are null values into memory queue. Then we remember the number of messages (say n) having been loaded. Second we query all messages that have null PAGE_ORD values and, after dropping the first n messages, update their PAGE_ORD values.

Option 1 is better. Option 2 is not so simple, as the first query may introduce new SQLs that have to use DB specific syntax. Here is the list of SQL for different DBs:

SELECT * FROM T LIMIT 10 OFFSET 20 	MySQL, PostgreSQL (also supports the standard, since version 8.4), SQLite, H2
SELECT * from T WHERE ROWNUM <= 10 	Oracle (also supports the standard, since Oracle8i)
SELECT FIRST 10 * from T 	Ingres
SELECT FIRST 10 * FROM T order by a 	Informix
SELECT SKIP 20 FIRST 10 * FROM T order by c, d 	Informix (row numbers are filtered after order by is evaluated. SKIP clause was introduced in a v10.00.xC4 fixpack)
SELECT * FROM T FETCH FIRST 10 ROWS ONLY 	DB2 (also supports the standard, in Linux, Windows, and Unix since DB2 v8, z/OS support added in v9)
SELECT TOP 10 * FROM T 	MS SQL Server (also supports the standard, since SQL Server 2005), Sybase ASE, MS Access
SELECT TOP 10 START AT 20 * FROM T 	Sybase SQL Anywhere (also supports the standard, since version 9.0.1)
SELECT FIRST 10 SKIP 20 * FROM T 	Interbase, Firebird
SELECT * FROM T ROWS 20 TO 30 	Firebird (since version 2.1)

http://en.wikipedia.org/wiki/Select_(SQL)


> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 23:50:29 2009
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Wed, 22 Jul 2009 23:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSER-116) Support
 deserialization generics objects
Message-ID: <2060572682.1248321029368.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Support deserialization generics objects
----------------------------------------

                 Key: JBSER-116
                 URL: https://jira.jboss.org/jira/browse/JBSER-116
             Project: JBoss Serialization
          Issue Type: Feature Request
    Affects Versions: 1.0.3 GA
            Reporter: Takayoshi Kimura
            Assignee: Clebert Suconic
         Attachments: GenericsTestCase.patch

Currently it seems JBoss Serialization doesn't support deserialization objects which contain a class using generics.

org.jboss.serial.exception.SerializationException: Could not create instance of org.jboss.serial.generics.GenericsTestCase$TestObject - org.jboss.serial.generics.GenericsTestCase$TestObject
	at org.jboss.serial.classmetamodel.ClassMetaData.newInstance(ClassMetaData.java:354)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:219)
	at org.jboss.serial.objectmetamodel.DefaultObjectDescriptorStrategy.readObject(DefaultObjectDescriptorStrategy.java:160)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:264)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescriptionInternal(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:53)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:725)
	at org.jboss.serial.io.JBossObjectInputStream.readObjectOverride(JBossObjectInputStream.java:211)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
	at org.jboss.serial.generics.GenericsTestCase.testGenerics(GenericsTestCase.java:56)
Caused by: java.lang.InstantiationException: org.jboss.serial.generics.GenericsTestCase$TestObject
	at java.lang.Class.newInstance0(Class.java:335)
	at java.lang.Class.newInstance(Class.java:303)
	at org.jboss.serial.classmetamodel.ClassMetaData.newInstance(ClassMetaData.java:346)
	... 24 more


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 23:09:29 2009
From: jira-events at lists.jboss.org (Jimmy Wilson (JIRA))
Date: Wed, 22 Jul 2009 23:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7120) Patch
 commons-logging so that Jasper doesn't use a deployment's logj4.jar when
 compiling a JSP in that deployment
In-Reply-To: <493131229.1248318449413.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1903086860.1248318569363.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jimmy Wilson updated JBAS-7120:
-------------------------------

    Attachment: commons-logging-1.1.0-jboss.diff-ur.patch


> Patch commons-logging so that Jasper doesn't use a deployment's logj4.jar when compiling a JSP in that deployment
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7120
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7120
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.0.0.GA, JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>            Reporter: Jimmy Wilson
>            Assignee: David Lloyd
>         Attachments: commons-logging-1.1.0-jboss.diff-ur.patch
>
>
> If a deployment (e.g. a WAR) packages its own log4j.jar then Jasper will use that log4j.jar when compiling the deployment's JSPs. This can cause unexpected behavior. Jasper should use JBoss' log4j.jar.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 23:07:29 2009
From: jira-events at lists.jboss.org (Jimmy Wilson (JIRA))
Date: Wed, 22 Jul 2009 23:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7120) Patch
 commons-logging so that Jasper doesn't use a deployment's logj4.jar when
 compiling a JSP in that deployment
Message-ID: <493131229.1248318449413.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Patch commons-logging so that Jasper doesn't use a deployment's logj4.jar when compiling a JSP in that deployment
-----------------------------------------------------------------------------------------------------------------

                 Key: JBAS-7120
                 URL: https://jira.jboss.org/jira/browse/JBAS-7120
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Logging
    Affects Versions: JBossAS-5.1.0.GA, JBossAS-5.0.1.GA, JBossAS-5.0.0.GA
            Reporter: Jimmy Wilson
            Assignee: David Lloyd


If a deployment (e.g. a WAR) packages its own log4j.jar then Jasper will use that log4j.jar when compiling the deployment's JSPs. This can cause unexpected behavior. Jasper should use JBoss' log4j.jar.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 22:03:29 2009
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Wed, 22 Jul 2009 22:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1682) duplicate key
 value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <370267132.1248314609373.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Takayoshi Kimura updated JBMESSAGING-1682:
------------------------------------------

    Affects Version/s: 1.4.0.SP3.CP06
                       1.4.0.SP3.CP05
                        1.4.0.SP3.CP04
                       1.4.0.SP3_CP03
                       1.4.0.SP3.CP02


Updated Affects Version/s to CP02-CP08.

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP02, 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 22:01:29 2009
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Wed, 22 Jul 2009 22:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1682) duplicate
 key value violates unique constraint "jbm_msg_pkey" exceptions in a
 clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <879066548.1248314489393.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Takayoshi Kimura reopened JBMESSAGING-1682:
-------------------------------------------



Reopen to update Affects Version/s.

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 22:03:29 2009
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Wed, 22 Jul 2009 22:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1682) duplicate key
 value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2084627038.1248314609586.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Takayoshi Kimura closed JBMESSAGING-1682.
-----------------------------------------

    Resolution: Done


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP02, 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 19:08:29 2009
From: jira-events at lists.jboss.org (Luca Stancapiano (JIRA))
Date: Wed, 22 Jul 2009 19:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPORTAL-2430) drag and drop and
 partial refresh in a region
In-Reply-To: <1129829044.1246720851383.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1113486798.1248304109199.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luca Stancapiano closed JBPORTAL-2430.
--------------------------------------

    Resolution: Done


of course,

committed in:

https://svn.jboss.org/repos/portal/branches/JBoss_Portal_Branch_2_7

and 

https://svn.jboss.org/repos/portal/branches/JBoss_Portal_Branch_2_7_AS5

> drag and drop and partial refresh in a region
> ---------------------------------------------
>
>                 Key: JBPORTAL-2430
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2430
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core, Portal Theme
>    Affects Versions: 2.7.2 Final
>         Environment: JBoss Portal 2.7.2 in JBoss 4.2.3 and JBoss 5.1
>            Reporter: Luca Stancapiano
>             Fix For: 2.8 Final
>
>
> hi... I added new properties inside the region. With this patch we can decide what region can use partial refresh or drag and drop feature. I've seen that this part is managed in the core but we cannot configure le sngle region for theese properties, so we was forced to use those properties in all the page. I added the two new properties in the org.jboss.portal.theme.tag.RegionTagHandler tag class:
>     private String dndEnabled = null;
>     private String partialRefreshEnabled = null;
> 	/**
> 	 * Attribute handler for the drag and drop of this tag
> 	 * <p>
> 	 * This field enables drag and drop on a chosen region
> 	 * </p>
> 	 * 
> 	 * @param dndEnabled
> 	 *            it can be true or false
> 	 */
> 	public void setDndEnabled(String dndEnabled) {
> 		this.dndEnabled = dndEnabled;
> 	}
>     /**
>      * Attribute handler for the partial refresh of this tag
>      * <p>
>      * This field enables partial refresh on a chosen region
>      * </p>
>      * 
>      * @param partialRefreshEnabled
>      *            it can be true or false
>      */
>     public void setPartialRefreshEnabled(String partialRefreshEnabled) {
>         this.partialRefreshEnabled = partialRefreshEnabled;
>     }
> and this part inside the doTag() method:
> 			
> 	    if (dndEnabled != null)
> 		rrc.getProperties().put(DynaRenderOptions.DND_ENABLED,
> 		      dndEnabled);
>             
>             if (partialRefreshEnabled != null)
>                 rrc.getProperties().put(DynaRenderOptions.PARTIAL_REFRESH_ENABLED,
>                       partialRefreshEnabled);
> I also updated tag descriptor portal-layout.tld inside core and theme projects adding the new properties:
> <taglib
>    xmlns="http://java.sun.com/xml/ns/j2ee"
>    xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd"
>    version="2.0">
>    <tlib-version>1.0</tlib-version>
>    <jsp-version>2.0</jsp-version>
>    <short-name></short-name>
>    <uri>http://www.jboss.org/portal</uri>
>    <tag>
>       <name>region</name>
>       <tag-class>org.jboss.portal.theme.tag.RegionTagHandler</tag-class>
>       <body-content>empty</body-content>
>       <attribute>
>          <name>orientation</name>
>       </attribute>
>       <attribute>
>          <name>regionName</name>
>       </attribute>
>       <attribute>
>          <name>regionID</name>
>       </attribute>
> <---------------------------------------
>       <attribute>
>          <name>dndEnabled</name>
>       </attribute>
>       <attribute>
>          <name>partialRefreshEnabled</name>
>       </attribute>
> ------------------------------------------
>    </tag>
> Now, when we want that only some regions uses this properties we can do inside our layout jsp something as:
> <p:region regionName='left' regionID='regionA' dndEnabled='true' partialRefreshEnabled='false'/>
> If we don't specify that two properties, the region will take the properties of the parent node as well as 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 18:20:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Jul 2009 18:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7119) org.jboss.Main
 doesn't "fix" jgroups.bind_addr passed via JAVA_OPTS
Message-ID: <671760334.1248301229382.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

org.jboss.Main doesn't "fix" jgroups.bind_addr passed via JAVA_OPTS
-------------------------------------------------------------------

                 Key: JBAS-7119
                 URL: https://jira.jboss.org/jira/browse/JBAS-7119
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-5.2.0.Beta1


The logic to "fix" a jgroups.bind_addr value of 0.0.0.0 is only kicking in if the value is passed as an argument to org.jboss.Main. If the value is specified as part of JAVA_OPTS, it gets passed directly to java and doesn't get fixed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 17:24:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Jul 2009 17:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7118) Update JGroups to
	2.6.11
In-Reply-To: <1930678592.1248289829128.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <837023707.1248297869606.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7118.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> Update JGroups to 2.6.11
> ------------------------
>
>                 Key: JBAS-7118
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7118
>             Project: JBoss Application Server
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Latest bug fix release.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 17:32:29 2009
From: jira-events at lists.jboss.org (Alex Skor (JIRA))
Date: Wed, 22 Jul 2009 17:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7071) use-try-lock
 option in data source configuration files is ignored
In-Reply-To: <329869123.1246546191859.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1387840036.1248298349382.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477237#action_12477237 ] 

Alex Skor commented on JBAS-7071:
---------------------------------

any plans for releasing 5.1.1 anytime soon with this and other fixes?

> use-try-lock option in data source configuration files is ignored
> -----------------------------------------------------------------
>
>                 Key: JBAS-7071
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7071
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows XP Professional V2002, service pack 3
>            Reporter: Mike Conner
>            Assignee: Jesper Pedersen
>            Priority: Minor
>
> (FYI  your "READ THIS BEFORE ENTERING NEW REPORTS" points to a  "You caught us doing a little maintenance..." page, so pardon me if I missed something in procedure. )
> The data source configuration property "use-try-lock" is effectively ignored.
> This is because the value is defined in configuration as a long, but the object that is actually set on  an
> org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory  extends 
>    org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnectionFactory
> This class defines it as taking an int, not a long:
>    public void setUseTryLock(int useTryLock)
> As such, reflection in ManagedConnectionFactoryDeployment.setManagedConnectionFactoryAttribute() does not find the method and simply logs it at a trace level, so the value never gets set.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 16:11:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 22 Jul 2009 16:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-536) Remove testsuite
 dependency on build-common.xml
Message-ID: <1269820757.1248293489189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Remove testsuite dependency on build-common.xml
-----------------------------------------------

                 Key: JBBUILD-536
                 URL: https://jira.jboss.org/jira/browse/JBBUILD-536
             Project: JBoss Build System
          Issue Type: Sub-task
            Reporter: Paul Gier
            Assignee: Paul Gier




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 16:15:30 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 22 Jul 2009 16:15:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-535) Move task
 configuration in server-config.xml into a target
In-Reply-To: <1701874410.1247777909261.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1068466024.1248293730732.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-535:
------------------------------

    Fix Version/s: Maven Build - App Server (Phase 3)


> Move task configuration in server-config.xml into a target
> ----------------------------------------------------------
>
>                 Key: JBBUILD-535
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-535
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the task definitions in server-config.xml are not inside a target.  This means that they can't depend on another target to define their path references.  This should be changed so that everything is done inside targets.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 16:13:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 22 Jul 2009 16:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-536) Remove testsuite
 dependency on build-common.xml
In-Reply-To: <1269820757.1248293489189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <567118861.1248293609117.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-536:
------------------------------

      Component/s: Maven Builds
    Fix Version/s: Maven Build - App Server (Phase 3)
      Description: The testsuite currently depends on buildmagic/build-common.xml.  This dependency should be removed so that buildmagic is no longer needed.


> Remove testsuite dependency on build-common.xml
> -----------------------------------------------
>
>                 Key: JBBUILD-536
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-536
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> The testsuite currently depends on buildmagic/build-common.xml.  This dependency should be removed so that buildmagic is no longer needed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 16:11:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 22 Jul 2009 16:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-419) Remove testsuite
 dependency on modules.ent
In-Reply-To: <20791453.1189779191245.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1629980288.1248293489140.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-419:
------------------------------

        Summary: Remove testsuite dependency on modules.ent  (was: Enable testsuite to run against maven generated artifacts.)
    Description: The testsuite uses modules.ent to build paths related to the module jars.  Instead these paths can be retrieved from the maven ant tasks.  (was: Once maven is able to generate matching artifacts for the ant build, the testsuite will have to be run against the maven generated stuff.  This will probably involve some modifications to the testsuite.)


> Remove testsuite dependency on modules.ent
> ------------------------------------------
>
>                 Key: JBBUILD-419
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-419
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> The testsuite uses modules.ent to build paths related to the module jars.  Instead these paths can be retrieved from the maven ant tasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 16:53:29 2009
From: jira-events at lists.jboss.org (Sean Han (JIRA))
Date: Wed, 22 Jul 2009 16:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2216) Drools call
 failed with CassCastException when the loca cache is turned on
Message-ID: <619212759.1248296009214.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Drools call failed with CassCastException when the loca cache is turned on
--------------------------------------------------------------------------

                 Key: JBRULES-2216
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2216
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.0.CR1
            Reporter: Sean Han
            Assignee: Mark Proctor


When the local cache is turned on, Drools call failed with the following exception:

java.lang.ClassCastException: org.drools.reteoo.BetaMemory cannot be cast to org.drools.reteoo.FromNode$FromMemory
	at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:93)
	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:145)
	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:57)
	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:142)
	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:42)
	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:184)
	at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:146)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1066)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1022)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:810)

Steps to reproduce:
   1. Turn on the local cache 
   2. Start the application using Drools
   3. Shut down Drools Guvnor
   4. Wait the poll period for Rule Agent
   5. Run the application with Drools rules
       You will see the exception.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 16:01:30 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Jul 2009 16:01:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7116) Improper handling of
 domain included in jvmRoute
In-Reply-To: <1089406326.1248204929175.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1236347431.1248292890435.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7116.
----------------------------------

    Resolution: Done


Note that some commits for this issue we're inadvertently committed under JBAS-7016.

> Improper handling of domain included in jvmRoute
> ------------------------------------------------
>
>                 Key: JBAS-7116
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7116
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Tomcat) service
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> org.jboss.web.tomcat.service.session.Util doesn't handle a domain.node as the jvmRoute format:
>    public static String getRealId(String sessionId)
>    {
>       int index = sessionId.lastIndexOf(".");  // WRONG!! Use String.indexOf('.', 0);
>       if (index > 0)
>       {
>          return sessionId.substring(0, index);
>       }
>       else
>       {
>          return sessionId;
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 16:07:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 22 Jul 2009 16:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-531) Remove testsuite
 dependency on libraries.ent
In-Reply-To: <6026725.1243637396349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <622647821.1248293249230.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-531:
------------------------------

        Summary: Remove testsuite dependency on libraries.ent  (was: Build testsuite classpaths directly against jars in local maven repository)
    Description: Currently the testsuite uses the jars in thirdparty via the file libraries.ent.  Instead the paths in the testsuite should directly reference jars in the local maven repository directory.  This can be done by building the paths with the maven ant tasks.  (was: Currently the testsuite uses the jars in thirdparty.  Instead the paths in the testsuite should directly reference jars in the local maven repository directory.)


> Remove testsuite dependency on libraries.ent
> --------------------------------------------
>
>                 Key: JBBUILD-531
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-531
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the testsuite uses the jars in thirdparty via the file libraries.ent.  Instead the paths in the testsuite should directly reference jars in the local maven repository directory.  This can be done by building the paths with the maven ant tasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 15:10:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Jul 2009 15:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7118) Update JGroups to
	2.6.11
Message-ID: <1930678592.1248289829128.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Update JGroups to 2.6.11
------------------------

                 Key: JBAS-7118
                 URL: https://jira.jboss.org/jira/browse/JBAS-7118
             Project: JBoss Application Server
          Issue Type: Component Upgrade
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: JBossAS-5.2.0.Beta1


Latest bug fix release.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 12:07:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 23 Jul 2009 12:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1876) CNFE on loading
 business interface of succesfully injected MBean in a quartz activated MDB
In-Reply-To: <461308215.1248363389242.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1975180285.1248365249375.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned EJBTHREE-1876:
--------------------------------------

    Assignee: jaikiran pai  (was: Andrew Lee Rubinger)


> CNFE on loading business interface of succesfully injected MBean in a quartz activated MDB
> ------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1876
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1876
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: JBoss 5.1.0.GA, JDK Java version: 1.6.0_14,Sun Microsystems Inc., Fedora 11-64bit
>            Reporter: Sanne Grinovero
>            Assignee: jaikiran pai
>
> Getting a classnotfound exception when trying to use a reference to a MBean, injected by annotations.
> Both MBean and the timer triggered MDB deploy correctly, also injection is working (something? is injected): the value of the reference is not null; as soon
> as a method is called on the injected object CNFE happens on the interface being the type of the reference itself.
> Please refer to the forum post for more details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 12:07:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 23 Jul 2009 12:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1876) CNFE on
 loading business interface of succesfully injected MBean in a quartz
 activated MDB
In-Reply-To: <461308215.1248363389242.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1125874307.1248365249538.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477304#action_12477304 ] 

jaikiran pai commented on EJBTHREE-1876:
----------------------------------------

Assigning to myself. Incorrectly assigned to ALR earlier.


> CNFE on loading business interface of succesfully injected MBean in a quartz activated MDB
> ------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1876
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1876
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: JBoss 5.1.0.GA, JDK Java version: 1.6.0_14,Sun Microsystems Inc., Fedora 11-64bit
>            Reporter: Sanne Grinovero
>            Assignee: jaikiran pai
>
> Getting a classnotfound exception when trying to use a reference to a MBean, injected by annotations.
> Both MBean and the timer triggered MDB deploy correctly, also injection is working (something? is injected): the value of the reference is not null; as soon
> as a method is called on the injected object CNFE happens on the interface being the type of the reference itself.
> Please refer to the forum post for more details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 12:38:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 22 Jul 2009 12:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1601) JMSBridge
 won't work with LargeMessages and resend
In-Reply-To: <12004607.1239904702467.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1498084585.1248280709621.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1601:
-----------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245368#4245368


> JMSBridge won't work with LargeMessages and resend
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1601
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1601
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> The JMS Bridge is caching a Message, and resending it when a failure occurs.
> On the case of a LargeMessage, the message should be received again instead of cached.
> Actually caching won't work with LargeMessages at all.
> There should be a config on JMSBridge that would complete disable caching, and the message would be received again in case of failure on either side (src or dest address). The user would need then to configure the JMSBridge accordingly to LargeMessages if that feature is being used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 12:19:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Wed, 22 Jul 2009 12:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7107) Invocation
 statistics not collected on JMX based EJB2 managed components
In-Reply-To: <381985128.1247839649313.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1847272553.1248279569653.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukas Krejci resolved JBAS-7107.
--------------------------------

    Resolution: Cannot Reproduce Bug


This seems to be a Jopr issue. Tracked by JOPR-280.

> Invocation statistics not collected on JMX based EJB2 managed components
> ------------------------------------------------------------------------
>
>                 Key: JBAS-7107
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7107
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>
> This was brought to light while investigating JOPR-280.
> During the Jopr AS5 plugin integration tests the metrics collection on EJB2 SFSBs, SLSBs, MDBs and Entity beans is tested.
> For session beans a single remote method is called 10 times on a single bean. The test then checks for CreateCount == 1 and for appropriate method invocation statistics.
> Both the create count and the invocation stats are always 0/empty. Note that this is also true for the MBeans of the session beans themselves when looking at the values in the jmx-console.
> For MDBs the collection statistics fails "most of the time". This might be because the JNDI name of a bean contains @object-id. Once some messages are delivered to the bean the @object-id part of the JNDI name changes from time to time. I suspect that with that change, the stats go as well.
> Entity bean metrics seem to be collected fine.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 11:57:29 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Wed, 22 Jul 2009 11:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6936) Testsuite fails
 during tests-profileservice target with IBM JDK 1.6 - AS instance not
 shutdown
In-Reply-To: <368622.1242662765255.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <212905887.1248278249220.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6936:
---------------------------------


These tests were excluded in this commit:
http://fisheye.jboss.org/changelog/JBossAS/?cs=91176

and they are not being run in the EAP-CI runs with IBM JDK 6:
http://hudson.qa.jboss.com/hudson/view/EAP-CI/job/JBoss-EAP-5.0.x-Testsuite-ibm16/31/testReport/org.jboss.test.deployers.seam.test/

where are you seeing the tests still being run?

> Testsuite fails during tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6936
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6936
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: threadDump.html
>
>
> The AS fails to start for the second time during the tests-profileservice target of the testsuite. This is caused by the first instance not being properly shutdown by the following ant command: <server:stop name="profileservice"/>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 11:21:29 2009
From: jira-events at lists.jboss.org (Martin Malina (JIRA))
Date: Wed, 22 Jul 2009 11:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6936) Testsuite fails
 during tests-profileservice target with IBM JDK 1.6 - AS instance not
 shutdown
In-Reply-To: <368622.1242662765255.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1419490700.1248276089209.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477192#action_12477192 ] 

Martin Malina commented on JBAS-6936:
-------------------------------------

I can confirm that after removing those 2 test cases (by simply removing the class files in output/classes) the second instance of AS starts up normally  and hence the whole tests-profileservice target runs normally (although there are some failures).
I didn't find out how to exclude the tests in build.xml - there already is a profileservice.excludes and it is excluding these test cases, but they get executed anyway. I'm not sure how it's supposed to work.

> Testsuite fails during tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6936
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6936
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: threadDump.html
>
>
> The AS fails to start for the second time during the tests-profileservice target of the testsuite. This is caused by the first instance not being properly shutdown by the following ant command: <server:stop name="profileservice"/>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 11:19:29 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Wed, 22 Jul 2009 11:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket write hangs inside a Lock,
 preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1052574282.1248275969322.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477191#action_12477191 ] 

Victor N commented on JGRP-1003:
--------------------------------

Forgot so say - I took stack traces 3 time with some intervals, it's interesting that one of threads (I marked it with ****) is always reading something from network:

"Connection.Sender [server1:40001 - server2:51740],TestCluster,server1:40001" prio=10 tid=0x08da7c00 nid=0x2a0e waiting on condition [0x1926d000..0x1926de40]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x77389808> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358)
*****	at org.jgroups.blocks.TCPConnectionMap$TCPConnection$Sender.run(TCPConnectionMap.java:594)
	at java.lang.Thread.run(Thread.java:619)

Maybe, this thread is blocked in socket read forever? Is SO_TIMEOUT set here?

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>         Attachments: jgroups_s2.txt, stacktrace.txt
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 09:40:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 22 Jul 2009 09:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7117) Classloader isolation
 test fails
 (org.jboss.test.classloader.test.ScopingUnitTestCase.testWarCommonsLoggingLog4jOverrides)
In-Reply-To: <587200004.1248269920988.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1024299303.1248270029169.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBAS-7117.
-----------------------------

    Resolution: Done


> Classloader isolation test fails (org.jboss.test.classloader.test.ScopingUnitTestCase.testWarCommonsLoggingLog4jOverrides)
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7117
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7117
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging, Web (Tomcat) service
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> We do not provide a "real" commons logging anymore.  Thus if an application wants to override logging by completely replacing commons logging plus the underlying framework of their choice (probably log4j) then they have to provide both JARs; therefore, we can no longer filter that package via the tomcat/src/resources/war-deployers-jboss-beans.xml directive.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 09:38:40 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 22 Jul 2009 09:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7117) Classloader
 isolation test fails
 (org.jboss.test.classloader.test.ScopingUnitTestCase.testWarCommonsLoggingLog4jOverrides)
Message-ID: <587200004.1248269920988.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Classloader isolation test fails (org.jboss.test.classloader.test.ScopingUnitTestCase.testWarCommonsLoggingLog4jOverrides)
--------------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-7117
                 URL: https://jira.jboss.org/jira/browse/JBAS-7117
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Logging, Web (Tomcat) service
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: JBossAS-6.0.0.Alpha1


We do not provide a "real" commons logging anymore.  Thus if an application wants to override logging by completely replacing commons logging plus the underlying framework of their choice (probably log4j) then they have to provide both JARs; therefore, we can no longer filter that package via the tomcat/src/resources/war-deployers-jboss-beans.xml directive.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 08:11:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 22 Jul 2009 08:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1506) Remove JMS &
 JDNI dependencies from MessagingXAResourceRecovery bean for JBoss AS 5.0
In-Reply-To: <12930667.1234454924508.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <531813802.1248264689276.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated JBMESSAGING-1506:
-------------------------------------

    Summary: Remove JMS & JDNI dependencies from MessagingXAResourceRecovery bean for JBoss AS 5.0  (was: Create XAResourceRecovery bean for JBoss AS 5.0)


> Remove JMS & JDNI dependencies from MessagingXAResourceRecovery bean for JBoss AS 5.0
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1506
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1506
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> POJO rather than MBean

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 07:25:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Wed, 22 Jul 2009 07:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-120) javax validation-api
	1.0.CR3
Message-ID: <105271748.1248261929139.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

javax validation-api 1.0.CR3
----------------------------

                 Key: JBJCA-120
                 URL: https://jira.jboss.org/jira/browse/JBJCA-120
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 07:27:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 22 Jul 2009 07:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1506) Create
 XAResourceRecovery bean for JBoss AS 5.0
In-Reply-To: <12930667.1234454924508.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1991457976.1248262049226.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477163#action_12477163 ] 

Tim Fox commented on JBMESSAGING-1506:
--------------------------------------

This bean should not rely on JNDI or use the JMS API for talking to the JBM server

> Create XAResourceRecovery bean for JBoss AS 5.0
> -----------------------------------------------
>
>                 Key: JBMESSAGING-1506
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1506
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> POJO rather than MBean

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 12:24:41 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Thu, 23 Jul 2009 12:24:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-86) support for
 org.jboss.util.StringPropertyReplacer in
 java.beans.PropertyEditor.getValue() implementations
Message-ID: <2136930207.1248366281283.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

support for org.jboss.util.StringPropertyReplacer in java.beans.PropertyEditor.getValue() implementations
---------------------------------------------------------------------------------------------------------

                 Key: JBCOMMON-86
                 URL: https://jira.jboss.org/jira/browse/JBCOMMON-86
             Project: JBoss Common
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: common-core (2.x)
    Affects Versions: 2.2.14.GA
         Environment: jboss 5.1.0.GA
            Reporter: Juergen none


e.g. properties like ${jboss.server.home.url} could be resolved by URLEditor, TextPropertyEditorSupport, ...

configurabe (on/off) ?
escaping? (e.g. \${jboss.server.home.url} for not resolving)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 06:51:29 2009
From: jira-events at lists.jboss.org (Tej jbpm (JIRA))
Date: Wed, 22 Jul 2009 06:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-367) Unable to delete
	process definition
Message-ID: <153388803.1248259889176.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Unable to delete process definition
-----------------------------------

                 Key: GPD-367
                 URL: https://jira.jboss.org/jira/browse/GPD-367
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM jPDL Designer 3.2
         Environment: Windows Vista, Eclipse 3.4.2, JBPM 3.2.1
            Reporter: Tej jbpm
            Assignee: Koen Aers


I am unable to delete process defitions after I set the notify="yes" in the  process definition. I see that there was a JIRA raised on this before and it was fixed in 3.2.2. but though I tried the fix mentioned it is still not working..

JIRA Reference : https://jira.jboss.org/jira/browse/JBPM-1043



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 07:06:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 22 Jul 2009 07:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1506) Create
 XAResourceRecovery bean for JBoss AS 5.0
In-Reply-To: <12930667.1234454924508.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1274293882.1248260789394.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned JBMESSAGING-1506:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> Create XAResourceRecovery bean for JBoss AS 5.0
> -----------------------------------------------
>
>                 Key: JBMESSAGING-1506
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1506
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> POJO rather than MBean

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 06:47:29 2009
From: jira-events at lists.jboss.org (Tej jbpm (JIRA))
Date: Wed, 22 Jul 2009 06:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-366) Process Definition not
 displayed correctly if xml is updated directly
Message-ID: <737619001.1248259649278.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Process Definition not displayed correctly if xml is updated directly
---------------------------------------------------------------------

                 Key: GPD-366
                 URL: https://jira.jboss.org/jira/browse/GPD-366
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM jPDL Designer 3.2
         Environment: Windows Vista, Eclispe 3.4.2 , JBPM 3.2.1
            Reporter: Tej jbpm
            Assignee: Koen Aers


Whenever I edit the processdefinition.xml directly for example ( I add a mail action class)..the original display in the processdefinition goes strange. IT loses all the transitions.

This does not  happen always. But intermittenly. Because of this whenever i change the xml file i save it and cross check it in the display whether everything is fine.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 05:50:29 2009
From: jira-events at lists.jboss.org (Carsten Ziegeler (JIRA))
Date: Wed, 22 Jul 2009 05:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2435)
 ResourceResponse.setContentLength throws UnsupportedOperationException
Message-ID: <1990585224.1248256229337.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

ResourceResponse.setContentLength throws UnsupportedOperationException
----------------------------------------------------------------------

                 Key: JBPORTAL-2435
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2435
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Portlet
    Affects Versions: 2.7.2 Final
            Reporter: Carsten Ziegeler


When calling ResourceResponse.setContentLength in a ResourceServingPortlet an UnsupportedOperationException is thrown

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 05:27:29 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Wed, 22 Jul 2009 05:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <936738787.1248254849704.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------

    Attachment: Test10K.jpg


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java, QueueExampleLong.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 05:27:30 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Wed, 22 Jul 2009 05:27:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <84109847.1248254850361.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------

    Attachment: Test100K.jpg


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java, QueueExampleLong.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 05:25:43 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Wed, 22 Jul 2009 05:25:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <201346735.1248254743501.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------


hi howard,
thanks for your feedback. i ran your example and it's working fine. since our application guys use JMS for handling large PDFs (generated by a scanner application, to be stored in an archive system) i took your example and
made the message size larger. in addition i put a loop around the execution instruction in the main() method => new QueueExampleLong().run(); to get this running in a loop one must also remove the System.exit() instruction in method
reportResultAndExit of class ExampleSupport.

running this code produces the OOM condition after approximately 194 rounds when running with a message size of 10000 bytes. when running with a size of 100000 bytes the OOM condition occurs after 20 rounds. these values multipled by factor
200 (number of sent messages) both calc up to approximately 390-400 MB. it looks like if the messages are being kept in memory, although doing a final commit() on the session and closing the connection.

attached you'll find the modified code QueueExampleLong.java and two images showing the java heap memory chart out of jconsole and the jboss console showing the OOM condition.
if i can help you any further with more testing or whatever, please let me know. thank you very much for your efforts putting into this.
regards martin 

> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java, QueueExampleLong.java
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 05:25:43 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Wed, 22 Jul 2009 05:25:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <658400348.1248254743775.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------

    Attachment: QueueExampleLong.java


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java, QueueExampleLong.java
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 04:54:29 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Wed, 22 Jul 2009 04:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket write hangs inside a Lock,
 preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1927877703.1248252869764.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477131#action_12477131 ] 

Victor N commented on JGRP-1003:
--------------------------------

Bela, I reproduced the problem again with the same symptoms - please look into the attached jgroups_s2.txt.

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>         Attachments: jgroups_s2.txt, stacktrace.txt
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 04:54:29 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Wed, 22 Jul 2009 04:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1003) deadlock in TP.send
 - socket write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1603006614.1248252869499.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Victor N updated JGRP-1003:
---------------------------

    Attachment: jgroups_s2.txt


> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>         Attachments: jgroups_s2.txt, stacktrace.txt
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 05:06:29 2009
From: jira-events at lists.jboss.org (Martin Malina (JIRA))
Date: Wed, 22 Jul 2009 05:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <763649194.1248253589621.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477134#action_12477134 ] 

Martin Malina commented on JBAS-7049:
-------------------------------------

OK, so as a temporary solution I included patching the config file to the corresponding Hudson job - it's now in the queue. Once I have a full run and see that the workaround works for me I will close this issue. The permanent solution will be when issue gets fixed in OpenJDK.

Also, we should document this in the Release Notes as a known issue - I will follow up on this with Rajesh.

> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 04:03:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Wed, 22 Jul 2009 04:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7097) Stack overflow
 error when establishing secured connection to Profile Service
Message-ID: <1139028683.1248249809474.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukas Krejci resolved JBAS-7097.
--------------------------------

    Resolution: Done


Haven't seen this in a while. Secured connections work flawlessly in EAP5 branch now.

> Stack overflow error when establishing secured connection to Profile Service
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7097
>             Project: JBoss Application Server
>          Issue Type: Bug
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Jopr rev902, AS5 EAP rev91190
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The stack overflow occurs in Jopr AS5 plugin AbstractProfileServiceConnection.init() after the connection has been established.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
>         at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
> Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
>         at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
>         at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
>         ... 12 more                                                                                                                                                                       
> Caused by: java.lang.StackOverflowError                                                                                                                                                   
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
> ....                                                                           
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
>         ... 18 more                                                                                                                                                                       

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 22 02:50:29 2009
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 22 Jul 2009 02:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2430) drag and drop
 and partial refresh in a region
In-Reply-To: <1129829044.1246720851383.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1497566173.1248245429171.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477119#action_12477119 ] 

Thomas Heute commented on JBPORTAL-2430:
----------------------------------------

Sounds good, you could apply it in Branch_2_7

> drag and drop and partial refresh in a region
> ---------------------------------------------
>
>                 Key: JBPORTAL-2430
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2430
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core, Portal Theme
>    Affects Versions: 2.7.2 Final
>         Environment: JBoss Portal 2.7.2 in JBoss 4.2.3 and JBoss 5.1
>            Reporter: Luca Stancapiano
>             Fix For: 2.8 Final
>
>
> hi... I added new properties inside the region. With this patch we can decide what region can use partial refresh or drag and drop feature. I've seen that this part is managed in the core but we cannot configure le sngle region for theese properties, so we was forced to use those properties in all the page. I added the two new properties in the org.jboss.portal.theme.tag.RegionTagHandler tag class:
>     private String dndEnabled = null;
>     private String partialRefreshEnabled = null;
> 	/**
> 	 * Attribute handler for the drag and drop of this tag
> 	 * <p>
> 	 * This field enables drag and drop on a chosen region
> 	 * </p>
> 	 * 
> 	 * @param dndEnabled
> 	 *            it can be true or false
> 	 */
> 	public void setDndEnabled(String dndEnabled) {
> 		this.dndEnabled = dndEnabled;
> 	}
>     /**
>      * Attribute handler for the partial refresh of this tag
>      * <p>
>      * This field enables partial refresh on a chosen region
>      * </p>
>      * 
>      * @param partialRefreshEnabled
>      *            it can be true or false
>      */
>     public void setPartialRefreshEnabled(String partialRefreshEnabled) {
>         this.partialRefreshEnabled = partialRefreshEnabled;
>     }
> and this part inside the doTag() method:
> 			
> 	    if (dndEnabled != null)
> 		rrc.getProperties().put(DynaRenderOptions.DND_ENABLED,
> 		      dndEnabled);
>             
>             if (partialRefreshEnabled != null)
>                 rrc.getProperties().put(DynaRenderOptions.PARTIAL_REFRESH_ENABLED,
>                       partialRefreshEnabled);
> I also updated tag descriptor portal-layout.tld inside core and theme projects adding the new properties:
> <taglib
>    xmlns="http://java.sun.com/xml/ns/j2ee"
>    xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd"
>    version="2.0">
>    <tlib-version>1.0</tlib-version>
>    <jsp-version>2.0</jsp-version>
>    <short-name></short-name>
>    <uri>http://www.jboss.org/portal</uri>
>    <tag>
>       <name>region</name>
>       <tag-class>org.jboss.portal.theme.tag.RegionTagHandler</tag-class>
>       <body-content>empty</body-content>
>       <attribute>
>          <name>orientation</name>
>       </attribute>
>       <attribute>
>          <name>regionName</name>
>       </attribute>
>       <attribute>
>          <name>regionID</name>
>       </attribute>
> <---------------------------------------
>       <attribute>
>          <name>dndEnabled</name>
>       </attribute>
>       <attribute>
>          <name>partialRefreshEnabled</name>
>       </attribute>
> ------------------------------------------
>    </tag>
> Now, when we want that only some regions uses this properties we can do inside our layout jsp something as:
> <p:region regionName='left' regionID='regionA' dndEnabled='true' partialRefreshEnabled='false'/>
> If we don't specify that two properties, the region will take the properties of the parent node as well as 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 23:17:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 21 Jul 2009 23:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-420) JBoss Security
 2.0.3.SP2 Release
In-Reply-To: <14028107.1245268807366.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1646238612.1248232649231.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed SECURITY-420.
----------------------------------

    Resolution: Done


> JBoss Security 2.0.3.SP2 Release
> --------------------------------
>
>                 Key: SECURITY-420
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-420
>             Project: JBoss Security and Identity Management
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX, Security SPI
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.3.SP2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 12:28:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 23 Jul 2009 12:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1876) CNFE on loading
 business interface of succesfully injected MBean in a quartz activated MDB
In-Reply-To: <461308215.1248363389242.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <758486227.1248366509196.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1876:
-----------------------------------

          Component/s: proxy-impl
    Affects Version/s: 1.1.5


> CNFE on loading business interface of succesfully injected MBean in a quartz activated MDB
> ------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1876
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1876
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: proxy-impl
>    Affects Versions: 1.1.5
>         Environment: JBoss 5.1.0.GA, JDK Java version: 1.6.0_14,Sun Microsystems Inc., Fedora 11-64bit
>            Reporter: Sanne Grinovero
>            Assignee: jaikiran pai
>
> Getting a classnotfound exception when trying to use a reference to a MBean, injected by annotations.
> Both MBean and the timer triggered MDB deploy correctly, also injection is working (something? is injected): the value of the reference is not null; as soon
> as a method is called on the injected object CNFE happens on the interface being the type of the reference itself.
> Please refer to the forum post for more details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 22:00:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 21 Jul 2009 22:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-415) ClientLoginModule
 multi-threaded=false should make SecurityContext client side association
In-Reply-To: <12517767.1244524256604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1765701887.1248228029336.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed SECURITY-415.
----------------------------------

    Resolution: Done


When the flag "multi-threaded" is set to false, then vmwide client security ctx association is established.

Remember never to set this flag inside JBoss AS.

> ClientLoginModule multi-threaded=false should make SecurityContext client side association
> ------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-415
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-415
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: JBossSecurity_2.0.3.SP1
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.3.SP2
>
>
> The ClientLoginModule multi-threaded=false option when missing, should set SecurityContextAssociation.setClient()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 19:19:29 2009
From: jira-events at lists.jboss.org (Sean Han (JIRA))
Date: Tue, 21 Jul 2009 19:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2215) RuleAgent gets
 NullPointerException when Drools guvnor server is not available
Message-ID: <1363755612.1248218369244.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

RuleAgent gets NullPointerException when Drools guvnor server is not available
------------------------------------------------------------------------------

                 Key: JBRULES-2215
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2215
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
         Environment: Linux 
            Reporter: Sean Han
            Assignee: Mark Proctor


RuleAgent gets NullPointerException when Drools guvnor server is not available.

Here is the exception: 
RuleAgent(default) EXCEPTION (Tue Jul 21 14:16:23 PDT 2009): Was unable to reach server.. Stack trace should follow.
java.io.IOException: Was unable to reach server.
	at org.drools.agent.URLScanner.hasChanged(URLScanner.java:155)
	at org.drools.agent.URLScanner.getChangeSet(URLScanner.java:119)
	at org.drools.agent.URLScanner.loadPackageChanges(URLScanner.java:96)
	at org.drools.agent.RuleAgent.checkForChanges(RuleAgent.java:410)
	at org.drools.agent.RuleAgent.refreshRuleBase(RuleAgent.java:362)
	at org.drools.agent.RuleAgent.configure(RuleAgent.java:347)
	at org.drools.agent.RuleAgent.init(RuleAgent.java:247)
	at org.drools.agent.RuleAgent.newRuleAgent(RuleAgent.java:187)
	at org.drools.agent.RuleAgent.newRuleAgent(RuleAgent.java:147)
	at org.drools.agent.RuleAgent.newRuleAgent(RuleAgent.java:256)
...
java.lang.NullPointerException
	at org.drools.agent.RuleAgent.refreshRuleBase(RuleAgent.java:363)
	at org.drools.agent.RuleAgent.configure(RuleAgent.java:347)
	at org.drools.agent.RuleAgent.init(RuleAgent.java:247)
	at org.drools.agent.RuleAgent.newRuleAgent(RuleAgent.java:187)
	at org.drools.agent.RuleAgent.newRuleAgent(RuleAgent.java:147)
	at org.drools.agent.RuleAgent.newRuleAgent(RuleAgent.java:256)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 18:55:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 21 Jul 2009 18:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1568)
 JournalStorageManager should not create large message directories in the
 constructor
In-Reply-To: <9568142.1239016462619.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <482001646.1248216929176.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1568.
----------------------------------------

    Resolution: Done


> JournalStorageManager should not create large message directories in the constructor
> ------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1568
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1568
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> In the JournalStorageManager constructor the various directories (bindings, message, large messages etc) are created.
> This is incorrect, the dirs should be checked and created in the start() method, otherwise the following will fail:
> jsm.start()
> jsm.stop();
> delete the directories
> jsm.start(); //fails
> jsm.stop();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 17:40:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 21 Jul 2009 17:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7116) Improper handling of
 domain included in jvmRoute
In-Reply-To: <1089406326.1248204929175.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <242008032.1248212429681.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated JBAS-7116:
-----------------------------------

    Workaround Description: 
Don't include the domain in the server.xml jvmRoute value; just use a distinct node name for each node. The mapping from node name to domain can be specified in the mod_jk or mod_cluster load balancer configuration and doesn't need to be included in the jvmRoute itself.

For configuring the domain with mod_jk, see the "domain" directive on http://tomcat.apache.org/connectors-doc/reference/workers.html.

For mod_cluster, see the "domain" attribute at http://www.jboss.org/mod_cluster/java/properties.html#proxy

                Workaround: [Workaround Exists]


> Improper handling of domain included in jvmRoute
> ------------------------------------------------
>
>                 Key: JBAS-7116
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7116
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Tomcat) service
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> org.jboss.web.tomcat.service.session.Util doesn't handle a domain.node as the jvmRoute format:
>    public static String getRealId(String sessionId)
>    {
>       int index = sessionId.lastIndexOf(".");  // WRONG!! Use String.indexOf('.', 0);
>       if (index > 0)
>       {
>          return sessionId.substring(0, index);
>       }
>       else
>       {
>          return sessionId;
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 15:35:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 21 Jul 2009 15:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7116) Improper handling of
 domain included in jvmRoute
Message-ID: <1089406326.1248204929175.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Improper handling of domain included in jvmRoute
------------------------------------------------

                 Key: JBAS-7116
                 URL: https://jira.jboss.org/jira/browse/JBAS-7116
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering, Web (Tomcat) service
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


org.jboss.web.tomcat.service.session.Util doesn't handle a domain.node as the jvmRoute format:

   public static String getRealId(String sessionId)
   {
      int index = sessionId.lastIndexOf(".");  // WRONG!! Use String.indexOf('.', 0);
      if (index > 0)
      {
         return sessionId.substring(0, index);
      }
      else
      {
         return sessionId;
      }
   }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 15:27:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Tue, 21 Jul 2009 15:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7097) Stack overflow
 error when establishing secured connection to Profile Service
Message-ID: <985961051.1248204449379.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477059#action_12477059 ] 

Charles Crouch commented on JBAS-7097:
--------------------------------------

Lukas, if you are happy this is fixed please resolve

> Stack overflow error when establishing secured connection to Profile Service
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7097
>             Project: JBoss Application Server
>          Issue Type: Bug
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Jopr rev902, AS5 EAP rev91190
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The stack overflow occurs in Jopr AS5 plugin AbstractProfileServiceConnection.init() after the connection has been established.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
>         at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
> Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
>         at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
>         at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
>         ... 12 more                                                                                                                                                                       
> Caused by: java.lang.StackOverflowError                                                                                                                                                   
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
> ....                                                                           
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
>         ... 18 more                                                                                                                                                                       

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 14:10:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 21 Jul 2009 14:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7115) Upgrade JSF to
	2.0.0-Beta2
In-Reply-To: <331422428.1248196049274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <324165394.1248199829201.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert resolved JBAS-7115.
--------------------------------

    Resolution: Done


> Upgrade JSF to 2.0.0-Beta2
> --------------------------
>
>                 Key: JBAS-7115
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7115
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: JBossAS-6.0.0.Alpha1
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: JBossAS-6.0.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 13:46:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Tue, 21 Jul 2009 13:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7114) Undeploy-deploy
 loop of directly referenced applications due to hasStructureBeenModified
In-Reply-To: <1522448733.1248183569203.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <533546655.1248198389516.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477050#action_12477050 ] 

Ales Justin commented on JBAS-7114:
-----------------------------------

We need to identify deployments somehow, and path name (relative path from root to deployment) was a logical choice.
Perhaps a workaround would be to have filter on the value + have root at file://home/.

But I see I need to re-think this mechanism, as your use case is valid.
Similar use case would be two exactly same named deployments in two different profile folders.
e.g. home/app.jar and deploy/app.jar, where home/ and deploy/ are roots



> Undeploy-deploy loop of directly referenced applications due to hasStructureBeenModified
> ----------------------------------------------------------------------------------------
>
>                 Key: JBAS-7114
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7114
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: VFS
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: 14:51:33,954 INFO  [ServerInfo] Java version: 1.6.0_14,Sun Microsystems Inc.
> 14:51:33,954 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
> 14:51:33,954 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 14.0-b16,Sun Microsystems Inc.
> 14:51:33,954 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 14:51:33,955 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Dcom.sun.management.jmxremote -Xms128m -Xmx1536m -XX:MaxPermSize=256m -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
>            Reporter: Juergen none
>            Assignee: Ales Justin
>
> in conf/bootstrap/profile.xml, applicationURIs:
> <value>file://home/login-service.sar</value>
> <value>file://home/app-local.ear</value>
> login-service.sar gets undeployed-redeployed every 5000 ms (HDScanner interval)
> from debugging:
> org.jboss.system.server.profileservice.repository.HotDeploymentRepository.getModifiedDeployments(), calling hasStructureBeenModified()
> for file://home/login-service.sar stays true
> both files share same root.getPathName() == "" !
> org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker.hasRootBeenModified():
> 1) root := app-local.ear: (app-local.ear).getPathName() == "", cached value for "" is null, put lastModified of (app-local.ear).getLastModified()
> 2) root := login-service.sar: (login-service.sar).getPathName() == "", cache value for "" is (app-local.ear).getLastModified() (<= (login-service.sar).getLastModified()) -> redeploy login-service.sar + getCache().invalidateCache(root.getPathName()): set "" to null
> 3) back to 1) -> loop

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 12:32:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 23 Jul 2009 12:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBLOGGING-21) make
 org.jboss.logging.filter.TCLFilter.isMatchingTCL() non-private for
 overriding purposes
In-Reply-To: <542988471.1248359684786.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1129024408.1248366749201.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned JBLOGGING-21:
------------------------------------

    Assignee: David Lloyd  (was: Dimitris Andreadis)


> make org.jboss.logging.filter.TCLFilter.isMatchingTCL() non-private for overriding purposes
> -------------------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-21
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-21
>             Project: JBoss Logging
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-log4j
>    Affects Versions: 2.1.0.GA-log4j
>         Environment: jboss-5.1.0.GA
>            Reporter: Juergen none
>            Assignee: David Lloyd
>         Attachments: RegExpTCLFilter.java
>
>
> I wanted to override TCLFilter to implement a RegExpTCLFilter, but because org.jboss.logging.filter.TCLFilter.isMatchingTCL() is declared private I could not subclass TCLFilter and just override that method.
> might be nice to change from private to protected

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 13:07:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 21 Jul 2009 13:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7115) Upgrade JSF to
	2.0.0-Beta2
Message-ID: <331422428.1248196049274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade JSF to 2.0.0-Beta2
--------------------------

                 Key: JBAS-7115
                 URL: https://jira.jboss.org/jira/browse/JBAS-7115
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JSF
    Affects Versions: JBossAS-6.0.0.Alpha1
            Reporter: Stan Silvert
            Assignee: Stan Silvert
             Fix For: JBossAS-6.0.0.Alpha1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 12:54:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 21 Jul 2009 12:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1568)
 JournalStorageManager should not create large message directories in the
 constructor
In-Reply-To: <9568142.1239016462619.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <245516211.1248195269657.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic reassigned JBMESSAGING-1568:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)


> JournalStorageManager should not create large message directories in the constructor
> ------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1568
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1568
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> In the JournalStorageManager constructor the various directories (bindings, message, large messages etc) are created.
> This is incorrect, the dirs should be checked and created in the start() method, otherwise the following will fail:
> jsm.start()
> jsm.stop();
> delete the directories
> jsm.start(); //fails
> jsm.stop();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 13:00:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 21 Jul 2009 13:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1686) Add more
 transactional options for the JCA adapter
In-Reply-To: <301051903.1247758289359.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1145247752.1248195629223.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1686:
-----------------------------------------

    Assignee: Andy Taylor  (was: Clebert Suconic)


Andy: I' m sending you this JIRA, as you told me you would be implementing as part of your current changes on the JCA.

> Add more transactional options for the JCA adapter
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1686
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1686
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>
> It should be possible to configure transactions for MDBs in a better fashion. Like receiving messages non-transactionally, or batching a number of transactions, even if this would mean non-compliant but activated by the user's choice.
> We already have:
> - Local Transaction
> - XA Transaction
> The options I'm thinking:
> We should add:
> - Batching transactions (commit on every X records... like most users do when processing a high number of messages outside the application server)
> - NonTransactional (messages being received non transactionally.. what should be good for Non Persistent Messages)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 12:58:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 21 Jul 2009 12:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1677) Ping faliures
 under heavy load
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <919065704.1248195509632.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1677:
-----------------------------------------

    Summary: Ping faliures under heavy load  (was: "Connection failure has been detected" message)


> Ping faliures under heavy load
> ------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>         Attachments: JmsTest-v2.zip, JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 12:56:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 21 Jul 2009 12:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <6701348.1248195389308.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1677:
-----------------------------------------

    Assignee: Andy Taylor  (was: Clebert Suconic)


> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>         Attachments: JmsTest-v2.zip, JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 12:58:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 21 Jul 2009 12:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1677) Ping faliures
 under heavy load
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1105492398.1248195509927.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1677.
----------------------------------------

    Resolution: Done


> Ping faliures under heavy load
> ------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>         Attachments: JmsTest-v2.zip, JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 21 12:30:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Tue, 21 Jul 2009 12:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-206) Expose remaining
 public methods in MainDeployer via interface
Message-ID: <741498768.1248193829261.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Expose remaining public methods in MainDeployer via interface
-------------------------------------------------------------

                 Key: JBDEPLOY-206
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-206
             Project: JBoss Deployers
          Issue Type: Task
          Components: maindeployer
    Affects Versions: JBDEPLOY-2.0.8.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For:  JBDEPLOY-2.2.x


In MainDeployerImpl we have some remaining public methods that lack proper interface.
They expose impl details, which should be used with care or not at all.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 12:36:29 2009
From: jira-events at lists.jboss.org (Sanne Grinovero (JIRA))
Date: Thu, 23 Jul 2009 12:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1876) CNFE on
 loading business interface of succesfully injected MBean in a quartz
 activated MDB
In-Reply-To: <461308215.1248363389242.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <50128562.1248366989170.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477309#action_12477309 ] 

Sanne Grinovero commented on EJBTHREE-1876:
-------------------------------------------

just discovered that from the MDB I get the same error when injecting a @Stateless bean: classnotfound on interface.
So it's not limited to the interaction with MBeans (Services)

> CNFE on loading business interface of succesfully injected MBean in a quartz activated MDB
> ------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1876
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1876
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: proxy-impl
>    Affects Versions: 1.1.5
>         Environment: JBoss 5.1.0.GA, JDK Java version: 1.6.0_14,Sun Microsystems Inc., Fedora 11-64bit
>            Reporter: Sanne Grinovero
>            Assignee: jaikiran pai
>
> Getting a classnotfound exception when trying to use a reference to a MBean, injected by annotations.
> Both MBean and the timer triggered MDB deploy correctly, also injection is working (something? is injected): the value of the reference is not null; as soon
> as a method is called on the injected object CNFE happens on the interface being the type of the reference itself.
> Please refer to the forum post for more details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 13:43:29 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Thu, 23 Jul 2009 13:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-742) Replace JBoss AOP
 ClassPools by JBoss ClassPools
Message-ID: <2063312568.1248371009352.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Replace JBoss AOP ClassPools by JBoss ClassPools
------------------------------------------------

                 Key: JBAOP-742
                 URL: https://jira.jboss.org/jira/browse/JBAOP-742
             Project: JBoss AOP
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone
             Fix For: 2.2.0.GA


The ClassPools that are being adapted for task JBREFLECT-3 should be used by JBoss AOP.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 14:30:29 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Thu, 23 Jul 2009 14:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREFLECT-55) Create a JBoss
 ClassPool project
Message-ID: <936584046.1248373829290.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Create a JBoss ClassPool project
--------------------------------

                 Key: JBREFLECT-55
                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-55
             Project: JBoss Reflection
          Issue Type: Sub-task
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone


This task consists of creating a jboss-classpool project, based on the ClassPools from JBoss AOP project. Such a project cannot have dependencies to JBoss AOP and should have all tests passing ok.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 14:46:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 23 Jul 2009 14:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-538) Remove any
 remaining buildmagic dependencies
Message-ID: <1146645968.1248374789318.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Remove any remaining buildmagic dependencies
--------------------------------------------

                 Key: JBBUILD-538
                 URL: https://jira.jboss.org/jira/browse/JBBUILD-538
             Project: JBoss Build System
          Issue Type: Sub-task
            Reporter: Paul Gier
            Assignee: Paul Gier




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 14:46:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 23 Jul 2009 14:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-537) Use target
 dependencies instead of antcall to avoid duplicate target invocations
In-Reply-To: <1059955584.1248374669143.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <598772069.1248374789258.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-537:
------------------------------

    Description: There are currently a lot of <antcall> in the testsuite.  Each antcall creates a new ant project instance and invokes all the dependencies of the invoked target.  Possibly this could be improved using either standard target dependencies, or using something like <calltarget> from the antcontrib tasks.


> Use target dependencies instead of antcall to avoid duplicate target invocations
> --------------------------------------------------------------------------------
>
>                 Key: JBBUILD-537
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-537
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>
> There are currently a lot of <antcall> in the testsuite.  Each antcall creates a new ant project instance and invokes all the dependencies of the invoked target.  Possibly this could be improved using either standard target dependencies, or using something like <calltarget> from the antcontrib tasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 14:48:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 23 Jul 2009 14:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-538) Remove any
 remaining buildmagic dependencies
In-Reply-To: <1146645968.1248374789318.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1253083681.1248374909187.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-538:
------------------------------

    Fix Version/s: Maven Build - App Server (Phase 3)


> Remove any remaining buildmagic dependencies
> --------------------------------------------
>
>                 Key: JBBUILD-538
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-538
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 14:48:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 23 Jul 2009 14:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-537) Use target
 dependencies instead of antcall to avoid duplicate target invocations
In-Reply-To: <1059955584.1248374669143.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <356905505.1248374909249.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-537:
------------------------------

    Fix Version/s: Maven Build - App Server (Phase 3)


> Use target dependencies instead of antcall to avoid duplicate target invocations
> --------------------------------------------------------------------------------
>
>                 Key: JBBUILD-537
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-537
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> There are currently a lot of <antcall> in the testsuite.  Each antcall creates a new ant project instance and invokes all the dependencies of the invoked target.  Possibly this could be improved using either standard target dependencies, or using something like <calltarget> from the antcontrib tasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 14:52:29 2009
From: jira-events at lists.jboss.org (Justin Waugh (JIRA))
Date: Thu, 23 Jul 2009 14:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2217) Array Index Out
 of Bounds in ClassFieldInspector with certain method signatures
In-Reply-To: <1755584026.1248374549289.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <286572206.1248375149502.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Justin Waugh updated JBRULES-2217:
----------------------------------

    Component/s: drools-core
                     (was: drools-compiler)


> Array Index Out of Bounds in ClassFieldInspector with certain method signatures
> -------------------------------------------------------------------------------
>
>                 Key: JBRULES-2217
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2217
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>         Environment: JBOSS 4.0.5, Windows Server 2003
>            Reporter: Justin Waugh
>            Assignee: Mark Proctor
>
> If a class has a method named setXXX but is not a traditional bean method, (particularly that it does not have a single parameter) an ArrayOutOfBoundsException will be thrown during class processing from ClassFieldInspector.storeGetterSetter (line 261).  This is because in ClassFieldInspector.processClassWithoutByteCode() it does not filter by method name prefix when trying to process get/is methods, but uses the common method ClassFieldInspector.addToMapping() to handle the method.
> an example problem method name would be:
> public void setTimestampFromCurrentTime();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 15:02:29 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Thu, 23 Jul 2009 15:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREFLECT-55) Create a JBoss
 ClassPool project
In-Reply-To: <936584046.1248373829290.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <669529526.1248375749362.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBREFLECT-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone closed JBREFLECT-55.
-----------------------------------

    Resolution: Done


The project is created at the location https://svn.jboss.org/repos/jbossas/projects/jboss-classpool, also available at http://anonsvn.jboss.org/repos/jbossas/projects/jboss-classpool

> Create a JBoss ClassPool project
> --------------------------------
>
>                 Key: JBREFLECT-55
>                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-55
>             Project: JBoss Reflection
>          Issue Type: Sub-task
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>
> This task consists of creating a jboss-classpool project, based on the ClassPools from JBoss AOP project. Such a project cannot have dependencies to JBoss AOP and should have all tests passing ok.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 15:02:29 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Thu, 23 Jul 2009 15:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBREFLECT-56) Adapt
 jboss-classpool so it works with JBoss AOP/JBoss AS
In-Reply-To: <1606896600.1248374309128.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2072341640.1248375749439.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBREFLECT-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone reassigned JBREFLECT-56:
---------------------------------------

    Assignee: Flavia Rainone


> Adapt jboss-classpool so it works with JBoss AOP/JBoss AS
> ---------------------------------------------------------
>
>                 Key: JBREFLECT-56
>                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-56
>             Project: JBoss Reflection
>          Issue Type: Sub-task
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>
> This task consists of adapting jboss-classpool so it can be used by JBoss AOP over JBoss AS.
> The goals of this task are:
> - to create a proved initial infrastructure for extending the project
> - to validate the class pools of jboss-classpool inside JBoss AS

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 15:04:29 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Thu, 23 Jul 2009 15:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREFLECT-57) Tidy up the
 jboss-classpool project
Message-ID: <1113420399.1248375869315.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Tidy up the jboss-classpool project
-----------------------------------

                 Key: JBREFLECT-57
                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-57
             Project: JBoss Reflection
          Issue Type: Sub-task
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone


This task consists of
- adding documentation
- adding missing tests, if any
- creating an spi
- refactoring (adding classes to appropriate packages, etc)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 15:23:29 2009
From: jira-events at lists.jboss.org (Justin Waugh (JIRA))
Date: Thu, 23 Jul 2009 15:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2217) Array Index Out
 of Bounds in ClassFieldInspector with certain method signatures
In-Reply-To: <1755584026.1248374549289.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1134356116.1248377009160.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Justin Waugh updated JBRULES-2217:
----------------------------------

    Description: 
If a class has a method named setXXX but is not a traditional bean method, (particularly that it does not have a single parameter and returns a value) an ArrayOutOfBoundsException will be thrown during class processing from ClassFieldInspector.storeGetterSetter (line 261).  This is because in ClassFieldInspector.processClassWithoutByteCode() it improperly detects the method as being a getter, because it does not filter by method name prefix when trying to process get/is methods, but uses the common method ClassFieldInspector.addToMapping() to handle the method. 

an example problem method name would be:

public boolean setDefaultValueAndCheckValidity();

Granted, methods like that might not be ideal programming style, but shouldn't break the processor





  was:
If a class has a method named setXXX but is not a traditional bean method, (particularly that it does not have a single parameter) an ArrayOutOfBoundsException will be thrown during class processing from ClassFieldInspector.storeGetterSetter (line 261).  This is because in ClassFieldInspector.processClassWithoutByteCode() it does not filter by method name prefix when trying to process get/is methods, but uses the common method ClassFieldInspector.addToMapping() to handle the method.

an example problem method name would be:

public void setTimestampFromCurrentTime();







> Array Index Out of Bounds in ClassFieldInspector with certain method signatures
> -------------------------------------------------------------------------------
>
>                 Key: JBRULES-2217
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2217
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>         Environment: JBOSS 4.0.5, Windows Server 2003
>            Reporter: Justin Waugh
>            Assignee: Mark Proctor
>
> If a class has a method named setXXX but is not a traditional bean method, (particularly that it does not have a single parameter and returns a value) an ArrayOutOfBoundsException will be thrown during class processing from ClassFieldInspector.storeGetterSetter (line 261).  This is because in ClassFieldInspector.processClassWithoutByteCode() it improperly detects the method as being a getter, because it does not filter by method name prefix when trying to process get/is methods, but uses the common method ClassFieldInspector.addToMapping() to handle the method. 
> an example problem method name would be:
> public boolean setDefaultValueAndCheckValidity();
> Granted, methods like that might not be ideal programming style, but shouldn't break the processor

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 15:31:42 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 15:31:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-131) OpenID Integration
In-Reply-To: <1207990758.1246906371307.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <147444521.1248377502173.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-131.
------------------------------

    Resolution: Done


> OpenID Integration
> ------------------
>
>                 Key: JBID-131
>                 URL: https://jira.jboss.org/jira/browse/JBID-131
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> Integrate Openid4Java which is ASL 2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 15:31:42 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 15:31:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-131) OpenID Integration
In-Reply-To: <1207990758.1246906371307.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <757829509.1248377502102.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-131:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha4
                       (was: IDFED-1.0.0.beta1)


> OpenID Integration
> ------------------
>
>                 Key: JBID-131
>                 URL: https://jira.jboss.org/jira/browse/JBID-131
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> Integrate Openid4Java which is ASL 2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 15:31:42 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 15:31:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-133) HTTP/Redirect binding
 : signature validation results are ignored (at the SP side as well as at
 the IDP side)
In-Reply-To: <1448773925.1247683709248.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <614315136.1248377502267.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-133:
-------------------------------

    Summary: HTTP/Redirect binding : signature validation results are ignored (at the SP side as well as at the IDP side)  (was: in the HTTP/Redirect binding, signature validation results are ignored (at the SP side as well as at the IDP side))


> HTTP/Redirect binding : signature validation results are ignored (at the SP side as well as at the IDP side)
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBID-133
>                 URL: https://jira.jboss.org/jira/browse/JBID-133
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Marcel Kolsteren
>            Assignee: Anil Saldhana
>
> When using signatures in the HTTP/Redirect binding, incorrect signatures don't lead to a negative authentication result.
> This is caused by the IDPRedirectValve and the SPRedirectFormAuthenticator. Both classes have a validate method that is overridden by the signature-enabled subclass. In both classes, the validate method is called, but the boolean result is ignored:
>          this.validate(request);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 15:41:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 15:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Work started: (JBID-133) HTTP/Redirect
 binding : signature validation results are ignored (at the SP side as well
 as at the IDP side)
In-Reply-To: <1448773925.1247683709248.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <909965883.1248378089654.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on JBID-133 started by Anil Saldhana.

> HTTP/Redirect binding : signature validation results are ignored (at the SP side as well as at the IDP side)
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBID-133
>                 URL: https://jira.jboss.org/jira/browse/JBID-133
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Marcel Kolsteren
>            Assignee: Anil Saldhana
>
> When using signatures in the HTTP/Redirect binding, incorrect signatures don't lead to a negative authentication result.
> This is caused by the IDPRedirectValve and the SPRedirectFormAuthenticator. Both classes have a validate method that is overridden by the signature-enabled subclass. In both classes, the validate method is called, but the boolean result is ignored:
>          this.validate(request);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 16:05:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 16:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-133) HTTP/Redirect binding
 : signature validation results are ignored (at the SP side as well as at
 the IDP side)
In-Reply-To: <1448773925.1247683709248.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1320338543.1248379529198.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-133:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha5


> HTTP/Redirect binding : signature validation results are ignored (at the SP side as well as at the IDP side)
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBID-133
>                 URL: https://jira.jboss.org/jira/browse/JBID-133
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Marcel Kolsteren
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> When using signatures in the HTTP/Redirect binding, incorrect signatures don't lead to a negative authentication result.
> This is caused by the IDPRedirectValve and the SPRedirectFormAuthenticator. Both classes have a validate method that is overridden by the signature-enabled subclass. In both classes, the validate method is called, but the boolean result is ignored:
>          this.validate(request);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 16:14:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 16:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-133) HTTP/Redirect binding
 : signature validation results are ignored (at the SP side as well as at
 the IDP side)
In-Reply-To: <1448773925.1247683709248.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2089301610.1248380069905.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-133.
------------------------------

    Resolution: Done


> HTTP/Redirect binding : signature validation results are ignored (at the SP side as well as at the IDP side)
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBID-133
>                 URL: https://jira.jboss.org/jira/browse/JBID-133
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Marcel Kolsteren
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> When using signatures in the HTTP/Redirect binding, incorrect signatures don't lead to a negative authentication result.
> This is caused by the IDPRedirectValve and the SPRedirectFormAuthenticator. Both classes have a validate method that is overridden by the signature-enabled subclass. In both classes, the validate method is called, but the boolean result is ignored:
>          this.validate(request);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 16:36:29 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 23 Jul 2009 16:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-2403) CMS Conditional
	GET
In-Reply-To: <18649384.1243398117117.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1586896217.1248381389215.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson updated JBPORTAL-2403:
-----------------------------------

    Fix Version/s: 2.7.3 Final


> CMS Conditional GET
> -------------------
>
>                 Key: JBPORTAL-2403
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2403
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.7.2 Final
>            Reporter: Mike Millson
>            Assignee: Sohil Shah
>             Fix For: 2.7.3 Final
>
>         Attachments: cms-conditional-get.patch
>
>
> Add support for conditional GET (304 response) for CMS content so clients can serve unmodified files from cache.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 17:13:29 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Thu, 23 Jul 2009 17:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTEST-13)
 JBossTestServices.login cannot let flushAuthCache fail
Message-ID: <1684894614.1248383609128.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBossTestServices.login cannot let flushAuthCache fail
------------------------------------------------------

                 Key: JBTEST-13
                 URL: https://jira.jboss.org/jira/browse/JBTEST-13
             Project: JBoss Test
          Issue Type: Bug
    Affects Versions: 1.1.4.GA
            Reporter: Scott M Stark
            Assignee: Scott M Stark


I created a test setup that set jbosstest.secure to true:

   public static Test suite() throws Exception
   {
      System.setProperty("jbosstest.secure", "true");
      System.setProperty("jbosstest.username", PROFILE_SERVICE_PRINCIPAL);
      System.setProperty("jbosstest.username", PROFILE_SERVICE_CREDENTIALS);
      
      TestSuite suite = new TestSuite();
      suite.addTest(new ProfileServiceUnitTestCase("testNonAdminProfileKeys"));
      suite.addTest(new ProfileServiceUnitTestCase("testProfileKeys"));
      return getDeploySetup(ProfileServiceUnitTestCase.class, suite, "testSecureProxies.beans");
   }

but this fails because the JBossTestServices.login fails because of a call to flushAuthCache before the login information has been set:

10132 [main] DEBUG org.jboss.test.profileservice.testsecure.ProfileServiceUnitTestCase  - args=[other]
java.lang.SecurityException: Failed to authenticate principal=null, securityDomain=jmx-console
	at org.jboss.jmx.connector.invoker.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:88)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
	at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
	at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
	at sun.rmi.transport.Transport$1.run(Transport.java:153)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
	at java.lang.Thread.run(Thread.java:613)
	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
	at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(JRMPInvoker_Stub.java:44)
	at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:133)
	at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
	at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
	at org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor.invoke(InvokerAdaptorClientInterceptor.java:66)
	at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:68)
	at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)
	at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101)
	at $Proxy0.invoke(Unknown Source)
	at org.jboss.test.JBossTestServices.invoke(JBossTestServices.java:239)
	at org.jboss.test.JBossTestServices.invoke(JBossTestServices.java:228)
	at org.jboss.test.JBossTestServices.flushAuthCache(JBossTestServices.java:367)
	at org.jboss.test.JBossTestServices.login(JBossTestServices.java:313)
	at org.jboss.test.JBossTestCase$1.setUp(JBossTestCase.java:301)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)

This needs to be caught and ignored.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 17:20:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 17:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-143) IDPWebBrowserSSOValve
 needs to use the validate method return value
Message-ID: <1837698266.1248384029219.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

IDPWebBrowserSSOValve needs to use the validate method return value
-------------------------------------------------------------------

                 Key: JBID-143
                 URL: https://jira.jboss.org/jira/browse/JBID-143
             Project: JBoss Identity
          Issue Type: Bug
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.alpha5




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 17:20:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 17:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-143) IDPWebBrowserSSOValve
 needs to use the validate method return value
In-Reply-To: <1837698266.1248384029219.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1491480685.1248384029326.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-143.
------------------------------

    Resolution: Done


> IDPWebBrowserSSOValve needs to use the validate method return value
> -------------------------------------------------------------------
>
>                 Key: JBID-143
>                 URL: https://jira.jboss.org/jira/browse/JBID-143
>             Project: JBoss Identity
>          Issue Type: Bug
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 17:23:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 17:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-144)
 SPPostFormAuthenticator needs to use the validate method return value
Message-ID: <46217206.1248384209082.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SPPostFormAuthenticator needs to use the validate method return value
---------------------------------------------------------------------

                 Key: JBID-144
                 URL: https://jira.jboss.org/jira/browse/JBID-144
             Project: JBoss Identity
          Issue Type: Sub-task
    Affects Versions: IDFED-1.0.0.alpha4
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.alpha5




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 17:25:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 17:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-144)
 SPPostFormAuthenticator needs to use the validate method return value
In-Reply-To: <46217206.1248384209082.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <364795506.1248384329124.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-144.
------------------------------

    Resolution: Done


> SPPostFormAuthenticator needs to use the validate method return value
> ---------------------------------------------------------------------
>
>                 Key: JBID-144
>                 URL: https://jira.jboss.org/jira/browse/JBID-144
>             Project: JBoss Identity
>          Issue Type: Sub-task
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 17:56:29 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Thu, 23 Jul 2009 17:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTEST-13)
 JBossTestServices.login cannot let flushAuthCache fail
In-Reply-To: <1684894614.1248383609128.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1015049189.1248386189241.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBTEST-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBTEST-13.
---------------------------------

    Resolution: Done


> JBossTestServices.login cannot let flushAuthCache fail
> ------------------------------------------------------
>
>                 Key: JBTEST-13
>                 URL: https://jira.jboss.org/jira/browse/JBTEST-13
>             Project: JBoss Test
>          Issue Type: Bug
>    Affects Versions: 1.1.4.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>
> I created a test setup that set jbosstest.secure to true:
>    public static Test suite() throws Exception
>    {
>       System.setProperty("jbosstest.secure", "true");
>       System.setProperty("jbosstest.username", PROFILE_SERVICE_PRINCIPAL);
>       System.setProperty("jbosstest.username", PROFILE_SERVICE_CREDENTIALS);
>       
>       TestSuite suite = new TestSuite();
>       suite.addTest(new ProfileServiceUnitTestCase("testNonAdminProfileKeys"));
>       suite.addTest(new ProfileServiceUnitTestCase("testProfileKeys"));
>       return getDeploySetup(ProfileServiceUnitTestCase.class, suite, "testSecureProxies.beans");
>    }
> but this fails because the JBossTestServices.login fails because of a call to flushAuthCache before the login information has been set:
> 10132 [main] DEBUG org.jboss.test.profileservice.testsecure.ProfileServiceUnitTestCase  - args=[other]
> java.lang.SecurityException: Failed to authenticate principal=null, securityDomain=jmx-console
> 	at org.jboss.jmx.connector.invoker.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:88)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
> 	at java.lang.Thread.run(Thread.java:613)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(JRMPInvoker_Stub.java:44)
> 	at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:133)
> 	at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
> 	at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
> 	at org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor.invoke(InvokerAdaptorClientInterceptor.java:66)
> 	at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:68)
> 	at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)
> 	at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101)
> 	at $Proxy0.invoke(Unknown Source)
> 	at org.jboss.test.JBossTestServices.invoke(JBossTestServices.java:239)
> 	at org.jboss.test.JBossTestServices.invoke(JBossTestServices.java:228)
> 	at org.jboss.test.JBossTestServices.flushAuthCache(JBossTestServices.java:367)
> 	at org.jboss.test.JBossTestServices.login(JBossTestServices.java:313)
> 	at org.jboss.test.JBossTestCase$1.setUp(JBossTestCase.java:301)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> This needs to be caught and ignored.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 17:58:29 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Thu, 23 Jul 2009 17:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTEST-13)
 JBossTestServices.login cannot let flushAuthCache fail
In-Reply-To: <1684894614.1248383609128.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1665554314.1248386309147.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBTEST-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark updated JBTEST-13:
--------------------------------

    Workaround Description: 
You can use a class specific delegate that overrides the login methods, for example:

   public static AbstractTestDelegate getDelegate(Class clazz) throws Exception
   {
      AbstractTestDelegate delegate = new JBossTestServices(clazz)
      {
         @Override
         public void login() throws Exception
         {
            String confName = System.getProperty("conf.name", "profileservice");
            AppCallbackHandler handler = new AppCallbackHandler(PROFILE_SERVICE_PRINCIPAL, PROFILE_SERVICE_CREDENTIALS.toCharArray());
            LoginContext loginContext = new LoginContext(confName, handler);
            loginContext.login();
            System.err.println("login as: "+PROFILE_SERVICE_PRINCIPAL);
         }
         
      };
      return delegate;
   }

                Workaround: [Workaround Exists]


> JBossTestServices.login cannot let flushAuthCache fail
> ------------------------------------------------------
>
>                 Key: JBTEST-13
>                 URL: https://jira.jboss.org/jira/browse/JBTEST-13
>             Project: JBoss Test
>          Issue Type: Bug
>    Affects Versions: 1.1.4.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>
> I created a test setup that set jbosstest.secure to true:
>    public static Test suite() throws Exception
>    {
>       System.setProperty("jbosstest.secure", "true");
>       System.setProperty("jbosstest.username", PROFILE_SERVICE_PRINCIPAL);
>       System.setProperty("jbosstest.username", PROFILE_SERVICE_CREDENTIALS);
>       
>       TestSuite suite = new TestSuite();
>       suite.addTest(new ProfileServiceUnitTestCase("testNonAdminProfileKeys"));
>       suite.addTest(new ProfileServiceUnitTestCase("testProfileKeys"));
>       return getDeploySetup(ProfileServiceUnitTestCase.class, suite, "testSecureProxies.beans");
>    }
> but this fails because the JBossTestServices.login fails because of a call to flushAuthCache before the login information has been set:
> 10132 [main] DEBUG org.jboss.test.profileservice.testsecure.ProfileServiceUnitTestCase  - args=[other]
> java.lang.SecurityException: Failed to authenticate principal=null, securityDomain=jmx-console
> 	at org.jboss.jmx.connector.invoker.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:88)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
> 	at java.lang.Thread.run(Thread.java:613)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(JRMPInvoker_Stub.java:44)
> 	at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:133)
> 	at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
> 	at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
> 	at org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor.invoke(InvokerAdaptorClientInterceptor.java:66)
> 	at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:68)
> 	at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)
> 	at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101)
> 	at $Proxy0.invoke(Unknown Source)
> 	at org.jboss.test.JBossTestServices.invoke(JBossTestServices.java:239)
> 	at org.jboss.test.JBossTestServices.invoke(JBossTestServices.java:228)
> 	at org.jboss.test.JBossTestServices.flushAuthCache(JBossTestServices.java:367)
> 	at org.jboss.test.JBossTestServices.login(JBossTestServices.java:313)
> 	at org.jboss.test.JBossTestCase$1.setUp(JBossTestCase.java:301)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> This needs to be caught and ignored.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 22:40:54 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Jul 2009 22:40:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2204) Exception not
 rethrown by AbstractWorkingMemory.executeQueuedActions()
In-Reply-To: <1550042503.1247265340995.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1828640197.1248403254406.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned JBRULES-2204:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)


> Exception not rethrown by AbstractWorkingMemory.executeQueuedActions() 
> -----------------------------------------------------------------------
>
>                 Key: JBRULES-2204
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2204
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>         Environment: JBoss AS 5.0, Windows Server 2003 SP2, Drools 5.0.1.FINAL
>            Reporter: Tom Murphy
>            Assignee: Edson Tirelli
>
> AbstractWorkingMemory.executeQueuedActions()  catches exceptions thrown within calls to action.execute() (line 1486). 
> It then tests to see if the exception is a RuntimeDroolsException and rethrows it if it is. However, if it is not, it simply does a printStackTrace() on the exception and does not re-throw it. This is a problem because SplitInstance throws an IllegalArgumentException on line 73. This is then caught and gobbled by the catch clause starting on line 1487 of AbstractWorkingMemory.java. 
> The result is that any service or application hosting the Drools runtime will never see this exception. What looks to the user like a clean (albeit overly shortened) rules session has in fact thrown an error, but it is not visible to the user or the owning service. It is therefore very difficult to diagnose why the rules and/or flows are not doing what they should.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 23 22:42:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Jul 2009 22:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2204) Exception not
 rethrown by AbstractWorkingMemory.executeQueuedActions()
In-Reply-To: <1550042503.1247265340995.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <146939901.1248403349197.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2204.
----------------------------------

    Fix Version/s: 5.1.0.M1
       Resolution: Done


Rethrowing the exception. 
Thanks for reporting.


> Exception not rethrown by AbstractWorkingMemory.executeQueuedActions() 
> -----------------------------------------------------------------------
>
>                 Key: JBRULES-2204
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2204
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>         Environment: JBoss AS 5.0, Windows Server 2003 SP2, Drools 5.0.1.FINAL
>            Reporter: Tom Murphy
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> AbstractWorkingMemory.executeQueuedActions()  catches exceptions thrown within calls to action.execute() (line 1486). 
> It then tests to see if the exception is a RuntimeDroolsException and rethrows it if it is. However, if it is not, it simply does a printStackTrace() on the exception and does not re-throw it. This is a problem because SplitInstance throws an IllegalArgumentException on line 73. This is then caught and gobbled by the catch clause starting on line 1487 of AbstractWorkingMemory.java. 
> The result is that any service or application hosting the Drools runtime will never see this exception. What looks to the user like a clean (albeit overly shortened) rules session has in fact thrown an error, but it is not visible to the user or the owning service. It is therefore very difficult to diagnose why the rules and/or flows are not doing what they should.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 00:56:29 2009
From: jira-events at lists.jboss.org (Vicky Kak (JIRA))
Date: Fri, 24 Jul 2009 00:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
In-Reply-To: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <895012303.1248411389504.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477384#action_12477384 ] 

Vicky Kak commented on JBAS-7086:
---------------------------------

We have this part of code missing in 
http://anonsvn.jboss.org/repos/jbossas/tags/JBoss_5_0_1_GA/connector/src/main/org/jboss/resource/metadata/mcf/XADataSourceDeploymentMetaData.java

************************************************************************************* 
      if(getIsSameRMOverrideValue() != null)
      {
         property = new ManagedConnectionFactoryPropertyMetaData();
         property.setName("IsSameRMOverrideValue");
         property.setType("java.lang.Boolean");
         property.setValue(String.valueOf(getIsSameRMOverrideValue()));
         properties.add(property);         
      }
************************************************************************************* 

It is already here 
http://anonsvn.jboss.org/repos/jbossas/tags/JBoss_5_1_0_GA/connector/src/main/org/jboss/resource/metadata/mcf/XADataSourceDeploymentMetaData.java

Also check this
https://jira.jboss.org/jira/browse/JBAS-5203

> Can't enlist in transaction with second Oracle XA connection/resource.
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7086
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager (Arjuna)
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: The operating system has been windows, but that doesn't appear to be related.
> Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
>            Reporter: Kevin Bates
>            Assignee: Jesper Pedersen
>
> We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.
> At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:
> 2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
> oracle.jdbc.xa.OracleXAException
> 	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
> 	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
> 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
> com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
> 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
> 	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
> 	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
> 	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:404)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy134.executeChanges(Unknown Source)
> 	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:378)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy135.executeChanges(Unknown Source)
> 	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
> 	at java.security.AccessController.doPrivileged(AccessController.java:284)
> 	at javax.security.auth.Subject.doAs(Subject.java:573)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
> 	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
> 	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:735)
> Caused by: 
> org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
> 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 	... 90 more
> Caused by: 
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 	... 92 more
> Caused by: 
> javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	... 96 more
> The two XA data sources are configured as follows:
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">OS1</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraGCDDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">GCD</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.
> Kind regards.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 05:09:29 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Fri, 24 Jul 2009 05:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6054) @EJB injection in
 JSP fails for local interface
In-Reply-To: <916085.1223412800943.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1882917501.1248426569328.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477400#action_12477400 ] 

Ondrej Medek commented on JBAS-6054:
------------------------------------

This issue is still in 5.1.0GA. It annoying when the EAR name changes, one has to change all mappedNames in the JSP pages.

> @EJB injection in JSP fails for local  interface
> ------------------------------------------------
>
>                 Key: JBAS-6054
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6054
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.0.0.CR2
>            Reporter: Wolfgang Knauf
>            Assignee: Carlo de Wolf
>         Attachments: Stateless.ear
>
>
> I will attach a sample for this problem.
> To verify the code:
> The attached EAR contains EJB, Web and ApplicationClient projects, one EJB "GeometricModelBean" with remote and local interfaces. The web project uses injection, the application client performs a JNDI lookup.
> The JSP  tries to inject a local and a remote interface in "GeometricModelTest.jsp" (http://localhost:8080/StatelessWeb/GeometricModelTest.jsp)
> <%!
>   @EJB()
>   GeometricModelRemote geometricModel;
>   @EJB()
>   GeometricModelLocal geometricModelLocal;
> %>
> The local interface injection will fail with this exception (from server console):
> 21:46:31,421 ERROR [FieldBeanProperty] failed to set value Proxy to jboss.j2ee:ear=Stateless.ear,jar=StatelessEJB.jar,name=GeometricModelBean,service=EJB3 implementing [interface org.jboss.ejb3.proxy.intf.EjbProxy, interface de.fhw.komponentenarchitekturen.knauf.stateless.GeometricModelRemote, interface org.jboss.ejb3.proxy.intf.SessionProxy] on field de.fhw.komponentenarchitekturen.knauf.stateless.GeometricModelLocal org.apache.jsp.GeometricModelTest_jsp.geometricModelLocal
> java.lang.IllegalArgumentException: Can not set de.fhw.komponentenarchitekturen.knauf.stateless.GeometricModelLocal field org.apache.jsp.GeometricModelTest_jsp.geometricModelLocal to $Proxy245
> 	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(Unknown Source)
> 	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(Unknown Source)
> 	at sun.reflect.UnsafeObjectFieldAccessorImpl.set(Unknown Source)
> 	at java.lang.reflect.Field.set(Unknown Source)
> 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:74)
> 	at org.jboss.injection.JndiPropertyInjector.inject(JndiPropertyInjector.java:119)
> 	at org.jboss.web.tomcat.service.TomcatInjectionContainer.processInjectors(TomcatInjectionContainer.java:361)
> 	at org.jboss.web.tomcat.service.TomcatInjectionContainer.processAnnotations(TomcatInjectionContainer.java:404)
> 	at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:261)
> 	at org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:145)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:322)
> 	.....
> It works, if I specifiy a "mappedName" attribute (pointing to the default bean name).
> <%!
>   @EJB()
>   GeometricModelRemote geometricModel;
>   @EJB(mappedName="Stateless/GeometricModelBean/local")
>   GeometricModelLocal geometricModelLocal;
> %>
> For servlets, the local interface injection works fine (also in the sample at URL http://localhost:8080/StatelessWeb/servlet/GeometricModelServlet)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 08:10:29 2009
From: jira-events at lists.jboss.org (Shital Mehta (JIRA))
Date: Fri, 24 Jul 2009 08:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2199)
 NullPointerException with JPA session persistence in Drools Flow
In-Reply-To: <233050457.1247060645508.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <127002592.1248437429266.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477436#action_12477436 ] 

Shital Mehta commented on JBRULES-2199:
---------------------------------------

Guys,

I hit the same problem. It seems persistence (or may be drools flow itself) is not a yet a widely used feature. I was just about to recommend drools in my company over jBPM 4.0 as I thought rules+workflow is a very powerful combination but will have to wait till drools seriously starts supporting long living workflow sessions.

> NullPointerException with JPA session persistence in Drools Flow
> ----------------------------------------------------------------
>
>                 Key: JBRULES-2199
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2199
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Alan Gairey
>            Assignee: Mark Proctor
>
> I'm currently using Drools Flow with JPA session persistence enabled as described in section 5.1 of the User Guide.
> As a process executes, session information is saved to the H2 database correctly.
> The problem comes when recreating a session from its persisted state, using the code:
> {code}
> // recreate the session from database using the sessionId
> ksession = JPAKnowledgeService.loadStatefulKnowledgeSession( sessionId, kbase, null, env );
> {code}
> This gives me a NullPointerException.
> Having looked into the Drools Flow source code, I think the problem is in the class drools-persistence-jpa\src\main\java\org\drools\persistence\session\SingleSessionCommandService.java.
> The 4th constructor of this class (starting line 132) is called as part of the loading of a knowledge session from the H2 database (i.e. via the code above); this in turn leads to the afterCompletion method of the inner class SynchronizationImpl being called. The final two lines of this method are:
> {code}
> ((JPAProcessInstanceManager) ((ReteooWorkingMemory) session).getProcessInstanceManager()).clearProcessInstances();
> ((JPAWorkItemManager) ((ReteooWorkingMemory) session).getWorkItemManager()).clearWorkItems();
> {code}
> However, when called via the route described above, the session member variable of SingleSessionCommandService has not been set, thus causing the NullPointerException.
> (Interestingly, running the unit tests for drools-persistence-jpa does result in a NullPointerException being thrown multiple times, although the tests are still listed as having passed.)
> I believe enclosing the above two lines as follows will fix the problem:
> {code}
> if (session != null) { 
>     ((JPAProcessInstanceManager) ((ReteooWorkingMemory) session).getProcessInstanceManager()).clearProcessInstances(); 
>     ((JPAWorkItemManager) ((ReteooWorkingMemory) session).getWorkItemManager()).clearWorkItems(); 
> } 
> {code}
> Also, in the 4th constructor of SingleSessionCommandService, after the session has been set, the following line needs to be added to ensure the session id is the same as the session info id:
> {code}
> ((ReteooStatefulSession) this.session).setId( this.sessionInfo.getId() );
> {code}
> (This line _is_ present at the end of the 3rd constructor - line 123.)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 09:09:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 24 Jul 2009 09:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
In-Reply-To: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1969570085.1248440969420.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBAS-7086:
----------------------------------

    Fix Version/s: JBossAS-5.1.0.GA


> Can't enlist in transaction with second Oracle XA connection/resource.
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7086
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager (Arjuna)
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: The operating system has been windows, but that doesn't appear to be related.
> Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
>            Reporter: Kevin Bates
>            Assignee: Jesper Pedersen
>             Fix For: JBossAS-5.1.0.GA
>
>
> We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.
> At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:
> 2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
> oracle.jdbc.xa.OracleXAException
> 	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
> 	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
> 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
> com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
> 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
> 	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
> 	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
> 	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:404)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy134.executeChanges(Unknown Source)
> 	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:378)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy135.executeChanges(Unknown Source)
> 	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
> 	at java.security.AccessController.doPrivileged(AccessController.java:284)
> 	at javax.security.auth.Subject.doAs(Subject.java:573)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
> 	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
> 	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:735)
> Caused by: 
> org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
> 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 	... 90 more
> Caused by: 
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 	... 92 more
> Caused by: 
> javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	... 96 more
> The two XA data sources are configured as follows:
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">OS1</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraGCDDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">GCD</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.
> Kind regards.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 09:11:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 24 Jul 2009 09:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
In-Reply-To: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2111977952.1248441089788.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen closed JBAS-7086.
---------------------------------

    Resolution: Done


> Can't enlist in transaction with second Oracle XA connection/resource.
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7086
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: The operating system has been windows, but that doesn't appear to be related.
> Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
>            Reporter: Kevin Bates
>            Assignee: Jesper Pedersen
>             Fix For: JBossAS-5.1.0.GA
>
>
> We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.
> At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:
> 2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
> oracle.jdbc.xa.OracleXAException
> 	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
> 	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
> 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
> com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
> 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
> 	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
> 	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
> 	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:404)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy134.executeChanges(Unknown Source)
> 	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:378)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy135.executeChanges(Unknown Source)
> 	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
> 	at java.security.AccessController.doPrivileged(AccessController.java:284)
> 	at javax.security.auth.Subject.doAs(Subject.java:573)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
> 	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
> 	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:735)
> Caused by: 
> org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
> 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 	... 90 more
> Caused by: 
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 	... 92 more
> Caused by: 
> javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	... 96 more
> The two XA data sources are configured as follows:
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">OS1</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraGCDDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">GCD</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.
> Kind regards.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 09:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 24 Jul 2009 09:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
In-Reply-To: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1449133197.1248441090204.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen reopened JBAS-7086:
-----------------------------------



> Can't enlist in transaction with second Oracle XA connection/resource.
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7086
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: The operating system has been windows, but that doesn't appear to be related.
> Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
>            Reporter: Kevin Bates
>            Assignee: Jesper Pedersen
>             Fix For: JBossAS-5.1.0.GA
>
>
> We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.
> At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:
> 2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
> oracle.jdbc.xa.OracleXAException
> 	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
> 	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
> 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
> com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
> 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
> 	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
> 	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
> 	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:404)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy134.executeChanges(Unknown Source)
> 	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:378)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy135.executeChanges(Unknown Source)
> 	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
> 	at java.security.AccessController.doPrivileged(AccessController.java:284)
> 	at javax.security.auth.Subject.doAs(Subject.java:573)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
> 	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
> 	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:735)
> Caused by: 
> org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
> 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 	... 90 more
> Caused by: 
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 	... 92 more
> Caused by: 
> javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	... 96 more
> The two XA data sources are configured as follows:
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">OS1</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraGCDDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">GCD</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.
> Kind regards.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 09:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 24 Jul 2009 09:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
In-Reply-To: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <53841627.1248441090544.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBAS-7086:
----------------------------------

    Component/s: JCA service
                     (was: Transaction Manager (Arjuna))


> Can't enlist in transaction with second Oracle XA connection/resource.
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7086
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: The operating system has been windows, but that doesn't appear to be related.
> Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
>            Reporter: Kevin Bates
>            Assignee: Jesper Pedersen
>             Fix For: JBossAS-5.1.0.GA
>
>
> We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.
> At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:
> 2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
> oracle.jdbc.xa.OracleXAException
> 	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
> 	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
> 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
> com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
> 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
> 	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
> 	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
> 	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:404)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy134.executeChanges(Unknown Source)
> 	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:378)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy135.executeChanges(Unknown Source)
> 	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
> 	at java.security.AccessController.doPrivileged(AccessController.java:284)
> 	at javax.security.auth.Subject.doAs(Subject.java:573)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
> 	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
> 	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:735)
> Caused by: 
> org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
> 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 	... 90 more
> Caused by: 
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 	... 92 more
> Caused by: 
> javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	... 96 more
> The two XA data sources are configured as follows:
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">OS1</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraGCDDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">GCD</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.
> Kind regards.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 09:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 24 Jul 2009 09:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
In-Reply-To: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1632084842.1248441090872.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen closed JBAS-7086.
---------------------------------

    Resolution: Done


> Can't enlist in transaction with second Oracle XA connection/resource.
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7086
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: The operating system has been windows, but that doesn't appear to be related.
> Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
>            Reporter: Kevin Bates
>            Assignee: Jesper Pedersen
>             Fix For: JBossAS-5.1.0.GA
>
>
> We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.
> At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:
> 2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
> oracle.jdbc.xa.OracleXAException
> 	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
> 	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
> 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
> com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
> 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
> 	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
> 	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
> 	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:404)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy134.executeChanges(Unknown Source)
> 	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:378)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy135.executeChanges(Unknown Source)
> 	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
> 	at java.security.AccessController.doPrivileged(AccessController.java:284)
> 	at javax.security.auth.Subject.doAs(Subject.java:573)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
> 	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
> 	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:735)
> Caused by: 
> org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
> 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 	... 90 more
> Caused by: 
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 	... 92 more
> Caused by: 
> javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	... 96 more
> The two XA data sources are configured as follows:
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">OS1</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraGCDDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">GCD</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.
> Kind regards.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 09:26:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 24 Jul 2009 09:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1506) Remove JMS &
 JDNI dependencies from MessagingXAResourceRecovery bean for JBoss AS 5.0
In-Reply-To: <12930667.1234454924508.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <864575658.1248441989368.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated JBMESSAGING-1506:
-------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=158856


> Remove JMS & JDNI dependencies from MessagingXAResourceRecovery bean for JBoss AS 5.0
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1506
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1506
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> POJO rather than MBean

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 09:26:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 24 Jul 2009 09:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1506) Remove JMS &
 JDNI dependencies from MessagingXAResourceRecovery bean for JBoss AS 5.0
In-Reply-To: <12930667.1234454924508.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1006286364.1248441989606.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1506.
------------------------------------

    Resolution: Done


fixed in the trunk

> Remove JMS & JDNI dependencies from MessagingXAResourceRecovery bean for JBoss AS 5.0
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1506
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1506
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> POJO rather than MBean

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 09:32:29 2009
From: jira-events at lists.jboss.org (Tihomir Surdilovic (JIRA))
Date: Fri, 24 Jul 2009 09:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7121) Upgrade to JSF
 1.2_13 in AS 5.x and trunk (6.x)
Message-ID: <716167156.1248442349151.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade to JSF 1.2_13 in AS 5.x and trunk (6.x) 
------------------------------------------------

                 Key: JBAS-7121
                 URL: https://jira.jboss.org/jira/browse/JBAS-7121
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JSF
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Tihomir Surdilovic
            Assignee: Stan Silvert


Upgrade to JSF 1.2_13 in AS 5.x and trunk (6.x).

 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:34:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 24 Jul 2009 11:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1672) AS 5 MBean
 Server integration
In-Reply-To: <32421204.1246267076495.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1080581803.1248449669371.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1672.
------------------------------------

    Resolution: Done


integration has been done but a bug in the jmx-console prevents to update attributes value for queues & addresses MBeans

> AS 5 MBean Server integration
> -----------------------------
>
>                 Key: JBMESSAGING-1672
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1672
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 2.0.0.beta3
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> When JBoss Messaging is integrated in AS 5, it should use AS 5's MBeanServer instead of the JVM's Platform MBeanServer to ensure JBoss Messaging is manageable through AS 5 jmx-console

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:32 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1675) add netty
 servlet firewall support when available.
In-Reply-To: <636963632.1246442671919.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1779502723.1248449912901.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1675:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> add netty servlet firewall support when available.
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1675
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1675
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 2.0.0.beta3
>            Reporter: Andy Taylor
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:33 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1671) Consider
 storing JMS destinations in their own journal instance
In-Reply-To: <11315556.1246092896416.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <687682251.1248449913069.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1671:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Consider storing JMS destinations in their own journal instance
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1671
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1671
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> We should consider storing JMS destinations in their own journal instance, and automatically deploy them into JNDI and management from this. This would mean that any JMS destinations created via the management interface would get redeployed on startup, which is not currently the case

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:33 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1666) Add
 "messageCount" attribute on Address MBean
In-Reply-To: <18851986.1245825537257.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1053371094.1248449913244.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1666:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Add "messageCount" attribute on Address MBean
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1666
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1666
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Value shown in "messageCount" attribute of a queue MBean does not include the number of messages that are paged. This is because messages are paged to disk  before they are routed in the postoffice. So, for the user to be able to find the total number of messages that are added to a queue, Tim suggested that, we add a "messageCount" attribute to the Address MBean. That would indicate how many messages are paged for a particular destination address.  Please refer http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157325 for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:33 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1649) redesign
 management replication
In-Reply-To: <1828892.1244729756776.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <884190512.1248449913387.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1649:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> redesign management replication
> -------------------------------
>
>                 Key: JBMESSAGING-1649
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1649
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> In order for management operation using JMX to be replicated, the MBeans are translating the management
> operation to a management messages which is sent to the management address using Core API. This allows
> for management messages to be properly replicated.
> However this allow forces the server to have an acceptor and a connector to talk to *itelsf* which is configusing
> and clutter the server configuration.
> The management code should be redesigned to be plugged directly on the server-side. The management 
> service'd no longer send a Core message using the Core API. Instead it'd call directly the ServerSessionPacketHandler
> (or equivalent) to handle a packet corresponding to the management message. It'll work since the handler will then
> replicate the packet correctly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:33 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1645)
	Multi-threaded replication
In-Reply-To: <19987581.1244635916851.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <905056941.1248449913539.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1645:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Multi-threaded replication
> --------------------------
>
>                 Key: JBMESSAGING-1645
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1645
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> Currently replication between live and backup node is done on a single thread. The operation is replicated, executed on backup, and when the result is returned to live, it is executed on live before the result is returned to the client (if applicable). This ensures the same ordering of state changes on live and backup but effectively makes all operation single threaded, thus reducing throughput in a clustered set-up.
> Instead we should implement multi-threaded replication. If replicated operations are being executed concurrently on backup it is more tricky to ensure that state changes on any object occur in the  same order as on live but it is possible.
> This is how we can do it.
> For the following types of objects it is important that their state changes occur in the same order on live and backup
> 1) Sessions (S)
> 2) Queues (Q)
> 3) Post offices. (P)
> Operations that occur on the live node are either
> a) Initiated externally - e.g. an operation like send message or acknowledge coming from a client
> b) Initiated internally - e.g. an asynchronous delivery, a depage, or an asynchronous message expiry from the reaper
> As any of these operations are being executed they may affect the state of one or more stateful objects, e.g. a send operation might affect the state of S1, Q1, Q2, S2, and S3 (as a sent message is routed to Q1 and Q2 and immediately delivered to S2 and S3).
> When the operation is replicated to the backup we must ensure that the state changes on any affected stateful objects must occur in the same order as they did on live.
> To do this as the operation is executed and the state changes occur, each stateful object is locked in turn, and a sequence number is obtained from the stateful object which tells us we're the nth stateful operation on that object.
> So a send operation might end up with a set of state sequences numbers:
> S1(12), Q1(102), Q2(32), S2 (74), S3 (1038)
> Which tells us the operation cause the 12th state change on object S1, followed by the 102nd state change on object Q1 etc.
> The list of sequence numbers can be stored in a thread local as the operation is executed on live.
> When the operation is executed on live we delay sending back any data to the client until we have replicate the operation to the backup and got a response that the replication has been processed.
> To ensure the state changes occur in the same order on backup, when we replicate the operation we also replicate the list state sequence numbers. When the operation is executed on the backup we attempt to obtain the locks on the stateful objects.
> Say we try to get the lock on object Q1, but the current sequence number of the object Q1 on the backup is 100, the attempt to get the lock will block until the 101st state change is executed since we require that operation is the 102nd state change.
> By using such a technique we can ensure that state changes are obtained in the same order on live and backup but are not limited to a single thread.
> In many cases the objects will be in the expected or similar sequence numbers so the replications can occur in parallel.
> In case of failure of the live node, operations may block indefinitely on the backup waiting for replications to arrive for missing state changes.
> For this we can timeout on the lock and reverse state changes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:33 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1635) Refactor
 HA-JNDI example to provide a real clustering test
In-Reply-To: <17016301.1243435835076.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1716073512.1248449913682.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1635:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Refactor HA-JNDI example to provide a real clustering test
> ----------------------------------------------------------
>
>                 Key: JBMESSAGING-1635
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1635
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Jeff Mesnil
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> our current javaee/hajndi does nothing (apart from opening connections)
> the example should be enhanced to demonstrate clustering feature *and* should
> be better automated (wrt to deployment and server starts/stops)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:33 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1626) The
 replicated queue could get out of order after Depage
In-Reply-To: <15212228.1242232787348.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1734484023.1248449913844.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1626:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> The replicated queue could get out of order after Depage
> --------------------------------------------------------
>
>                 Key: JBMESSAGING-1626
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1626
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> In an edge case scenario, where there are too many subscriptions during page/depage the backup node queue could get out of order what would cause issues with replicateDelivery.
> similar to what happened on JBMESSAGING-1558

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:33 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1609) Provide
 Destination deploying through Beans
In-Reply-To: <12195779.1240853506474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1480733777.1248449913978.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1609:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Provide Destination deploying through Beans
> -------------------------------------------
>
>                 Key: JBMESSAGING-1609
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1609
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> This should be very simple to implement.
> An user may choose to deploy a destination using Beans, so he could hot-deploy queues with his applications in a way it would work with MDBs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:34 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1601) JMSBridge
 won't work with LargeMessages and resend
In-Reply-To: <12004607.1239904702467.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1270846338.1248449914134.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1601:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> JMSBridge won't work with LargeMessages and resend
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1601
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1601
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> The JMS Bridge is caching a Message, and resending it when a failure occurs.
> On the case of a LargeMessage, the message should be received again instead of cached.
> Actually caching won't work with LargeMessages at all.
> There should be a config on JMSBridge that would complete disable caching, and the message would be received again in case of failure on either side (src or dest address). The user would need then to configure the JMSBridge accordingly to LargeMessages if that feature is being used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:34 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1589) Soak tests
In-Reply-To: <10099911.1239023242682.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <407958377.1248449914250.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1589:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Soak tests
> ----------
>
>                 Key: JBMESSAGING-1589
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1589
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Add soak tests.
> For normal use cases+ failover, paging etc.
> Should run for several days.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:34 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1588) Add netty
	bridge tests
In-Reply-To: <23146682.1239023123744.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <974893598.1248449914345.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1588:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Add netty bridge tests
> ----------------------
>
>                 Key: JBMESSAGING-1588
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1588
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:34 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1587) Add trace
	logging
In-Reply-To: <26091288.1239023123317.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <607712787.1248449914458.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1587:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Add trace logging
> -----------------
>
>                 Key: JBMESSAGING-1587
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1587
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Add trace logging throughout, will aid in diagnosing issues in a production environment.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:34 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1584) Client side
 load balancing integration tests
In-Reply-To: <16160411.1239022283313.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1816231999.1248449914562.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1584:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Client side load balancing integration tests
> --------------------------------------------
>
>                 Key: JBMESSAGING-1584
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1584
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> We need tests for this, that test different policies etc.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:34 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1583) Fix message
 redistribution with replication
In-Reply-To: <28198275.1239022282568.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <53210970.1248449914676.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1583:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Fix message redistribution with replication
> -------------------------------------------
>
>                 Key: JBMESSAGING-1583
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1583
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> Message redistribution in a replicated cluster is currently broken. Needs to be fixed and thoroughly tested.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:34 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1572) Sent to DLQ
 if routeFromCluster fails
In-Reply-To: <6577331.1239017542713.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1576467953.1248449914777.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1572:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Sent to DLQ if routeFromCluster fails
> -------------------------------------
>
>                 Key: JBMESSAGING-1572
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1572
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> If routeFromCluster fails e.g. if queue has been deleted after sending on source, then message should go to DLQ not be deleted.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:34 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1570) Why does
 QueueImpl::changeMessagePriority delete the ref?
In-Reply-To: <3627699.1239016823311.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1760101156.1248449914948.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1570:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Why does QueueImpl::changeMessagePriority delete the ref?
> ---------------------------------------------------------
>
>                 Key: JBMESSAGING-1570
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1570
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> QueueImpl::changeMessagePriority seems to delete the old ref from storage then only add the new one in memory!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:35 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1569) Add test for
 failing onto backup, then copying backup dir
In-Reply-To: <14314443.1239016463248.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2050906689.1248449915037.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1569:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Add test for failing onto backup, then copying backup dir
> ---------------------------------------------------------
>
>                 Key: JBMESSAGING-1569
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1569
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Add a test for server failing over to backup doing some work, closing both down, then copying over data directory from backup to live and restarting

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:35 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1567) Statically
 wired clusters and initial/reconnection
In-Reply-To: <7470014.1239016342551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1257084863.1248449915170.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1567:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Statically wired clusters and initial/reconnection
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1567
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1567
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Statically wired clusters have problems  when a node fails, since the backup node will try and connect its bridges to the failed node when activated and just get into an endless loop doing that, since the connection manager will always try and connect on the first node

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:35 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1566) Temporary
 Destinations should not allow their consumers to be created on other
 connections than their own as per JMS spec
In-Reply-To: <18089367.1238683225226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <760823051.1248449915294.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1566:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Temporary Destinations should not allow their consumers to be created on other connections than their own as per JMS spec
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1566
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1566
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Howard Gao
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> JMS 1.1 spec Section 4.4.3 2nd paragraph:
> Temporary destinations (TemporaryQueue or TemporaryTopic objects) are
> destinations that are system-generated uniquely for their connection. Only
> their own connection is allowed to create MessageConsumers for them.
> So the following test should fail, but currently it passes.
>    public void testTemporaryQueueScope()
>    {
>       try
>       {
>          senderConnection.stop();
>          receiverConnection.stop();
>          tempQueue = receiverSession.createTemporaryQueue();
>          //create consumer on different connection, should fail!
>          senderSession.createConsumer(tempQueue);
>       }
>       catch (JMSException e)
>       {
>          fail(e);
>       }
>    }
> The same issue exists with temporary topics too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:35 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1565) Need to check
 permissions on create producer for JMS
In-Reply-To: <21193950.1238568922429.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <829079277.1248449915373.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1565:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Need to check permissions on create producer for JMS
> ----------------------------------------------------
>
>                 Key: JBMESSAGING-1565
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1565
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> For JMS, we need to check permissions when creating a JMS message producer. However if we do this in JBossSession (currently commented out), then sending management messages to JMS fails since there is no actual management queue.
> The code in JBossSession is temporarily commented out until this is resolved.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:32 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1687) Transaction
 management/demarcation and ack modes/session creation broken in JCA RA
In-Reply-To: <615256574.1247823389304.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1618164653.1248449912645.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1687:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Transaction management/demarcation and ack modes/session creation broken in JCA RA
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1687
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1687
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Andy Taylor
>            Priority: Critical
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:32 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1686) Add more
 transactional options for the JCA adapter
In-Reply-To: <301051903.1247758289359.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <750875441.1248449912781.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1686:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Add more transactional options for the JCA adapter
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1686
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1686
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>
> It should be possible to configure transactions for MDBs in a better fashion. Like receiving messages non-transactionally, or batching a number of transactions, even if this would mean non-compliant but activated by the user's choice.
> We already have:
> - Local Transaction
> - XA Transaction
> The options I'm thinking:
> We should add:
> - Batching transactions (commit on every X records... like most users do when processing a high number of messages outside the application server)
> - NonTransactional (messages being received non transactionally.. what should be good for Non Persistent Messages)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:35 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1557) Race
 condition in JMS Bridge between enlisting the XAResource in the TX and
 message delivery
In-Reply-To: <19430245.1237906402584.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <174663418.1248449915490.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1557:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Race condition in JMS Bridge between enlisting the XAResource in the TX and message delivery
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1557
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1557
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Jeff Mesnil
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> The JMS Bridge code is enlisting the XAResource in the JTA Transaction in a way that can occur concurrently with delivery.
> more info: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=151340&start=10

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:35 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1556) Add
 additional core management notifications
In-Reply-To: <4089038.1237901302475.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1910316261.1248449915635.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1556:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Add additional core management notifications
> --------------------------------------------
>
>                 Key: JBMESSAGING-1556
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1556
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Add additional management notifications for the following events in JBM server:
> 1/ notifications for start/stop of some messaging component: 
> - ACCEPTOR_STARTED / ACCEPTOR_STOPPED 
> - BRIDGE_STARTED / BRIDGE_STOPPED 
> - BROADCAST_GROUP_STARTED / BROADCAST_GROUP_STOPPED 
> - CLUSTER_CONNECTION_STARTED / CLUSTER_CONNECTION_STOPPED 
> - DISCOVERY_GROUP_STARTED / DISCOVERY_GROUP_STOPPED 
> 2/ I was also thinking to add notifications when messages are expired/moved to the dead letter address but I'm not sure these notifications should be enabled by default (they can potentially generate a lot of notifications): 
> EXPIRED_MESSAGE -> when a message is expired 
> MOVED_TO_DEAD_LETTER_ADDRESS -> when a message is moved to the DLA 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:35 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1553) Record list
 of heuristically committed/rolledback transaction branches
In-Reply-To: <1117527.1237565242427.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1516981622.1248449915758.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1553:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Record list of heuristically committed/rolledback transaction branches
> ----------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1553
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1553
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Currently when heuristically committing or rolling back a transaction branch via the management interface we don't record the list of Xids for the committed/rolled back branches.
> If the tx mgr calls commit/rollback and we have already heuristically committed/rolled back then we need to return XA_HEURCOM, so we need the list persisted in order to do this.
> When the tx mgr calls forget, then we can remove them.
> We should add a management method to list the two lists.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:36 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1484) Rename base
	package name
In-Reply-To: <17920878.1231877584176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1289326451.1248449916520.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1484:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Rename base package name
> ------------------------
>
>                 Key: JBMESSAGING-1484
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1484
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Rename org.jboss.messaging to something else.
> Suggestions are:
> org.jboss.jbm
> ....

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:36 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1463) Possible
 Orphaned Files On LargeMessages
In-Reply-To: <31199513.1228862686838.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1309629825.1248449916649.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1463:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Possible Orphaned Files On LargeMessages
> ----------------------------------------
>
>                 Key: JBMESSAGING-1463
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1463
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> If the server crash after the .tmp file is renamed, and before it is added to Journal or Paging, it may be orphaned.
> The possible fix would probably be to inspect the Page and Journal Files and find out what files are orphaned. 
> Maybe we could delay the verification until an user with admin privileges request to identify orphaned files through management.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:36 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1536) Optimisation
In-Reply-To: <9922377.1236104062518.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <586793703.1248449916161.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1536:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Optimisation
> ------------
>
>                 Key: JBMESSAGING-1536
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1536
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Various system optimisations:
> 1) Optimise message routing. We can probably combine preroute and route. Also in BindingsImpl we can  avoid creation of so many sets, and use array based logic instead.
> 2) Optimise SimpleString - intern() where appropriate
> 3) Optimise journal direct byte buffers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:36 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1528) Re-enable
 producer flow control when adress is full
In-Reply-To: <31530726.1236100462526.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <791582351.1248449916287.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1528:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Re-enable producer flow control when adress is full
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1528
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1528
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> This can be done by holding back packet confirmations until more space frees up.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:36 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1526) Improve
 timeout when closing consumer
In-Reply-To: <20211796.1236099982846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2105813072.1248449916382.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1526:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Improve timeout when closing consumer
> -------------------------------------
>
>                 Key: JBMESSAGING-1526
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1526
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Currently if there are a lot of messages in a client consumer buffer and they are being consumed by a slow consumrt, then on close, it will timeout since it will wait for all messages to be consumed. Need to improve this so it only waits for the current one to complete.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:36 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1433) Enable
 replication for browsers
In-Reply-To: <3332141.1224406292113.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1492917767.1248449916772.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1433:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Enable replication for browsers
> -------------------------------
>
>                 Key: JBMESSAGING-1433
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1433
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> Making a copy of the queue for a browser consumer doesn't work well with replication since
> When replicating the create consumer (browser) to the backup, when executed on the backup the
> backup may have different messages in its queue since been added on different threads.
> So when replicating deliveries they may not be found.
> Uncomment MultiThreadRandomFailoverTest::testM when this is complete.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:36 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1432)
 ReceiveImmediate on consumer should check the server for messages
In-Reply-To: <2499468.1224263600985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1342193053.1248449916909.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1432:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> ReceiveImmediate on consumer should check the server for messages
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-1432
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1432
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Andy Taylor
>            Assignee: Tim Fox
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> When receiveImmediate() is called on a client consumer it only checks its internal buffer. It should also check with the server to make sure there are no messages in transit or waiting to be delivered. Once this is done the Queue Browser can be changed to use this instead of a timeout receive.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:37 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1427) Journal
	Cleanup
In-Reply-To: <6551971.1222785211162.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1756330686.1248449917028.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1427:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Journal Cleanup
> ---------------
>
>                 Key: JBMESSAGING-1427
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1427
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 2.0.0 Alpha
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> If a destination is lazy, not consuming messages for a long time, the journal will grow until those messages are consumed.
> This would be a problem with DLQs or messages taking days before they are consumed.
> Since we inform the TransactionSummary on commits, we could change the journal to support multiple current-files based on configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:37 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1424) Provider
 strict message ordering via "ordering groups"
In-Reply-To: <25015723.1222415841133.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <400847157.1248449917135.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1424:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Provider strict message ordering via "ordering groups"
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1424
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1424
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> See linked task

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:37 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1335) Network
 disconnect reconnect testing
In-Reply-To: <8721677.1211911069404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <921848019.1248449917734.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1335:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Network disconnect reconnect testing
> ------------------------------------
>
>                 Key: JBMESSAGING-1335
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1335
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> We need to do full network disconnect reconnect testing with JBM2.0. For bridge, for split brain etc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:37 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1330) Allow maxSize
 (etc) to be specified when creating a queue using core API
In-Reply-To: <1151134.1211908139552.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1240911584.1248449917867.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1330:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Allow maxSize (etc) to be specified when creating a queue using core API
> ------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1330
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1330
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:38 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1325) Sync a backup
 server with a live server
In-Reply-To: <2662823.1211906159940.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2016758875.1248449918335.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1325:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Sync a backup server with a live server
> ---------------------------------------
>
>                 Key: JBMESSAGING-1325
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1325
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> If a live server has no backup server, should be able to bring one up while the live is running and for them to auto-sync.
> This is useful if the server has failed over to its backup, and you won't to bring up another backup for the failed over server.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:38 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1316) code cleanup
 - final fields and params
In-Reply-To: <14607629.1211904890487.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2128563076.1248449918744.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1316:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> code cleanup - final fields and params
> --------------------------------------
>
>                 Key: JBMESSAGING-1316
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1316
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Make sure final fields and properties are used where appropriate.
> Also static inner classes are used, and fields made private.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:39 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1315) Implement
 client "freeze" test
In-Reply-To: <10914498.1211904649509.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1073052205.1248449919839.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1315:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Implement client "freeze" test
> ------------------------------
>
>                 Key: JBMESSAGING-1315
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1315
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Implement a test which freezes (hangs) a client, and makes sure the server disconnects it without the server freezing or delivery getting blocked.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:40 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1194) Support
 quorum for mitigating split brain
In-Reply-To: <21675614.1197367312287.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1734941471.1248449920014.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1194:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Support quorum for mitigating split brain
> -----------------------------------------
>
>                 Key: JBMESSAGING-1194
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1194
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:40 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1149) Singleton
 consumer on queue/topic
In-Reply-To: <15322200.1194961485037.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1240791928.1248449920198.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1149:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Singleton consumer on queue/topic
> ---------------------------------
>
>                 Key: JBMESSAGING-1149
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1149
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.4.0.SP1
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> A last minute requirement came up from the AS team (Carlo and Bill DeCoste).
> JBoss MQ uses HA singleton to provide a singleton consumer on a queue/topic. If that node fails, the consumer should failover onto another single node.
> Currently this isn't supported in JBM.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:40 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1090) Add
 appropriate Exception handling when hitting MaxSize
In-Reply-To: <9488820.1191326763359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <591637858.1248449920378.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1090:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Add appropriate Exception handling when hitting MaxSize
> -------------------------------------------------------
>
>                 Key: JBMESSAGING-1090
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1090
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Messaging Core
>    Affects Versions: 1.4.0.GA
>            Reporter: Jay Howell
>            Assignee: Tim Fox
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> When using MaxSize for a queue and topic the following behaviors exist
> Queue - When a queue hits MaxSize, the delivery returned in Channel Support is null.  This triggers a very generic JMSException to be thrown by looking at the delivery and seeing if it's null in the ServerConnectionEndpoint.
> Topic - When a subscription hits the MaxSize(defined in the topic), the delivery returned will be null, but no check is done and no JMSException is thrown in the ServerConnectionEndpoint.
> What this means is that anyone who wants to put hooks in to gather the messages dropped can't.  Either because the exception is too generic or because one is not thrown at all.
> I would purpose that we put proper exception handling down in the ChannelSupport where MaxSize is checked for both queues and subscriptions.  
> We would need to Change the The two methods in channel support for send and sendInternal to throw a JMSException.  Then we throw a checked Exception in ChannelSupport for MaxSize violations(make a new exception derived from MessagingJMSException).  
> Adding proper exception handling to these would allow users to add aspects and notifications when messages are dropped due to MaxSize.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:40 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-753) Distribute ant
 with the distro
In-Reply-To: <31300965.1169039633086.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1741982130.1248449920518.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-753:
----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Distribute ant with the distro
> ------------------------------
>
>                 Key: JBMESSAGING-753
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-753
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Build System
>            Reporter: Galder Zamarreno
>            Assignee: Tim Fox
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> Add to source and make messaging add it to the binary distribution 
> under util directory. That should speed up patching AS for customers 
> and would guarantee that they use the Ant version that we want them to use.
> This is currently implemented in JBC and JGroups and I find it very useful.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:37 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1400) Allow users
 to configure a system wide maximum connection limit
In-Reply-To: <8050340.1216224002198.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <98774192.1248449917279.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1400:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Allow users to configure a system wide maximum connection limit
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1400
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1400
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Jay Howell
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Many users are complaining of errors that say "Too many open files", which comes from the number of sockets open during jms processing. It's currently possible to run the system out of resources.  We currently only have control of this through the remoting/netty/mina layer.  We should have a setting in JBM that limits the number of connections systemwide, that is independent of the remoting protocol/package.  This way users wouldn't have to keep learning a new package/configuration setting each time the communications package changes in jbm.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:37 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1399) Allow users
 to configure a system wide maximum session limit
In-Reply-To: <4175115.1216223127220.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <676139401.1248449917409.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1399:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Allow users to configure a system wide maximum session limit
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1399
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1399
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>            Reporter: Jay Howell
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Goal: keep external/internal clients from running the system out of resources(threads/memory).
> We currently have a problem where there is no limit to the number of sessions that can be created in the system.  It would be theoretically possible to have an external client create 1 million sessions in one connection and run the sever out of resources.   It's also possible to set the number of max sessions for an mdb high enough to run the system out of resources(threads/memory).  We need to be able to set a limit for the number of sessions for the system. 
> I've looked at other Messaging systems, like IBM MQ and it seems that other systems have the same setting. 
> We've had users naively suggest that we could implement this by using a bounded thread pool.  This seems too intrusive and too dangerous to do.  This can be done by limiting the number of sessions in the system, which seems like a much better suggestion.  This is much better than using a bounded thread pool for many reasons.  A couple of the reasons is..
> 1.  It doesn't expose the internal workings of JBM to the management console(leaky abstraction).  
> 2.  Users can understand a session limit easier than having to understand the internal thread pool implementation.
> 3.  Doesn't incur deadlocks
> 4.  Allows All clients to get back a message that says some thing like "Session limit reached".
> JBM 2.0 uses an unbounded thread pool for threads, which addresses any concern any performance difficulties with creating and destroying threads.  So now we can address the max number of threads in the system by configuring max sessions in the system.
> Setting a session limit seems to be a more reasonable approach than the bounded thread pool

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:37 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1375) Validate if
 the journal directory is ext3 or ext2
In-Reply-To: <17094750.1213643913298.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <840268036.1248449917537.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1375:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Validate if the journal directory is ext3 or ext2
> -------------------------------------------------
>
>                 Key: JBMESSAGING-1375
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1375
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0 Alpha
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> If the journal dir is anything different than ext2 or ext3, we should use NIO instead.
> This includes SMB or Network mount points.
> a SAN should work fine as long as you use ext2 or 3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:40 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-390)
 ConnectionFactory and JBossDestination should be Referenceable
Message-ID: <1966462748.1248449920660.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-390:
----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> ConnectionFactory and JBossDestination should be Referenceable
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-390
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-390
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> as per spec 4.2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:40 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-377) Competing
 consumer on subscriptions
Message-ID: <1761037278.1248449920765.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-377:
----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Competing consumer on subscriptions
> -----------------------------------
>
>                 Key: JBMESSAGING-377
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-377
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Minor
>             Fix For: 2.0.0
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> We should add an ability to have competing consumers on (durable) subscriptions. This will allow us to load balance processing of messages from a durable subscription across multiple consumers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:40 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-375) Grouping of
	messages
Message-ID: <1145940547.1248449920958.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-375:
----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Grouping of messages
> --------------------
>
>                 Key: JBMESSAGING-375
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-375
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Tim Fox
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>         Attachments: jbmessaging-375.patch, patch-JBMESSAGING-375.txt, patch-JBMESSAGING-375.txt
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> We should add an ability to group messages by a group id so any messages with the same group id always go to the same consumer on a queue.
> This would be useful when having competing consumers on a queue and you want each consumer to handle all messages with a particular value of group id.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:41 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-357) Update design
	documentation
Message-ID: <1162780442.1248449921108.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-357:
----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Update design documentation
> ---------------------------
>
>                 Key: JBMESSAGING-357
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-357
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Documentation and Training
>            Reporter: Ovidiu Feodorov
>             Fix For: 2.0.0
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Make sure design documentation for JBM 2 exists and is up to date.
> All areas of design should be documentated.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:41 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-211) Destination
 programmatic deployment example/integration test
Message-ID: <1173673275.1248449921280.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-211:
----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Destination programmatic deployment example/integration test
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-211
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-211
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>            Priority: Optional
>             Fix For: 2.0.0
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Write the corresponing docs/example/programmatic-deployment integration test.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:41 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-152) Refactor
	exception handling
Message-ID: <1177390210.1248449921455.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-152:
----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Refactor exception handling
> ---------------------------
>
>                 Key: JBMESSAGING-152
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-152
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: JMS Facade
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Minor
>             Fix For: 2.0.0
>
>   Original Estimate: 1 day, 4 hours
>  Remaining Estimate: 1 day, 4 hours
>
> We should audit the exception handling.
> In some areas it is quite sloppy including anti-patterns such as:
> 1. Logging errors when they're not being handled
> 2. Rethrowing with less information. E.g. losing the message or original exception.
> 3. Too much usage of "throws Throwable" or "throws Exception" where probably unnecessary.
> 4. Swallowing exceptions.
> We need to go through the whole of the code, auditing and changing as necessary.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:35 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1550) Core
 BridgeConfiguration with a discovery group is not deployed
In-Reply-To: <22813655.1237480462871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1647486600.1248449915906.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1550:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Core BridgeConfiguration with a discovery group is not deployed
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1550
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1550
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Jeff Mesnil
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> A Core BridgeConfiguration can be set with either a discovery group or a pair of connectors.
> When the bridge is deployed (in ClusterManager.start()), we only check for the pair of connectors.
> If the bridge config uses a discovery group, it will never be deployed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:38:35 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1542) Add more
 failover tests for paging
In-Reply-To: <5860634.1236203362692.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <461833121.1248449915994.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1542:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Add more failover tests for paging
> ----------------------------------
>
>                 Key: JBMESSAGING-1542
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1542
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:42:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1504) Full Journal
	Compactation
In-Reply-To: <33137475.1234453664451.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <618182898.1248450149547.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic reopened JBMESSAGING-1504:
------------------------------------------



> Full Journal Compactation
> -------------------------
>
>                 Key: JBMESSAGING-1504
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1504
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>            Priority: Critical
>             Fix For: 2.0.0.beta4
>
>
> Let me describe how I think the compacting should work.
> Let's say we have a set of files in the journal:
> F0, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10
> min files is set to 10
> The current file is F6 and F7, F8, F9, F10 are unused files waiting to be used
> F0, F1, F2, F3, F4, F5 are files full of data and not open any more, however, data about their contents are stored in memory.
> We need a compacting thread that intermittently (say every 30 seconds) scans the set of journal files in memory.
> It scans F0... F5, and when it has completed that scan, it can decide which records are no longer needed in each file.
> A record is no longer needed in a file if it has already been deleted in any file F0.. F5.
> Once the scanner thread has computed which records are needed and which are not, it can compute a percentage of which records in total are dead space.
> E.g. the scanner might compute that 72% of the data in files F0.. .F5 are dead space.
> We then have a parameter that the user can configure compactorDeadSpaceThresholdPercentage, e.g. this might have a default of 75%.
> If the amount of dead space computed by the scanner >= compactorDeadSpaceThresholdPercentage, then the scanner will compact those files.
> The actual compacting approach goes as follows:
> The scanner knows how many new files it will need for the compacted records, let's say it needs two new files - it can get these from the unused files (e.g. F7, F8, F9 or F10) if they are available.
> It then opens the old files F0..F5 loads the wanted records into memory in blocks and copies them to the new files.
> When this process is finished it will end up with, say, two new files containing the compacted records.
> We can then save a marker file (empty in the journal directory) which says we are starting the rename.
> The old files F0..F5 then need to be renamed so they are no longer used by the journal (but can be recovered in case of a crash).
> Then the two new files need to be renamed so they will be picked up by the journal.
> When that process completes the marker file can be deleted.
> If the server crashes after renaming the old files but before renaming the new files, then the marker file will still exist in the journal. The journal can detect this on startup, and finish the process.
> This ensures the journal will still startup after such a crash.
> Also the JournalFile objects also need to be updated in memory when the compact is complete.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:42:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1504) Full Journal
	Compactation
In-Reply-To: <33137475.1234453664451.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2013384667.1248450149727.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1504:
-----------------------------------------

    Issue Type: Feature Request  (was: Task)


> Full Journal Compactation
> -------------------------
>
>                 Key: JBMESSAGING-1504
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1504
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>            Priority: Critical
>             Fix For: 2.0.0.beta4
>
>
> Let me describe how I think the compacting should work.
> Let's say we have a set of files in the journal:
> F0, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10
> min files is set to 10
> The current file is F6 and F7, F8, F9, F10 are unused files waiting to be used
> F0, F1, F2, F3, F4, F5 are files full of data and not open any more, however, data about their contents are stored in memory.
> We need a compacting thread that intermittently (say every 30 seconds) scans the set of journal files in memory.
> It scans F0... F5, and when it has completed that scan, it can decide which records are no longer needed in each file.
> A record is no longer needed in a file if it has already been deleted in any file F0.. F5.
> Once the scanner thread has computed which records are needed and which are not, it can compute a percentage of which records in total are dead space.
> E.g. the scanner might compute that 72% of the data in files F0.. .F5 are dead space.
> We then have a parameter that the user can configure compactorDeadSpaceThresholdPercentage, e.g. this might have a default of 75%.
> If the amount of dead space computed by the scanner >= compactorDeadSpaceThresholdPercentage, then the scanner will compact those files.
> The actual compacting approach goes as follows:
> The scanner knows how many new files it will need for the compacted records, let's say it needs two new files - it can get these from the unused files (e.g. F7, F8, F9 or F10) if they are available.
> It then opens the old files F0..F5 loads the wanted records into memory in blocks and copies them to the new files.
> When this process is finished it will end up with, say, two new files containing the compacted records.
> We can then save a marker file (empty in the journal directory) which says we are starting the rename.
> The old files F0..F5 then need to be renamed so they are no longer used by the journal (but can be recovered in case of a crash).
> Then the two new files need to be renamed so they will be picked up by the journal.
> When that process completes the marker file can be deleted.
> If the server crashes after renaming the old files but before renaming the new files, then the marker file will still exist in the journal. The journal can detect this on startup, and finish the process.
> This ensures the journal will still startup after such a crash.
> Also the JournalFile objects also need to be updated in memory when the compact is complete.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:42:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1504) Full Journal
	Compactation
In-Reply-To: <33137475.1234453664451.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1489464161.1248450149958.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1504.
----------------------------------------

    Resolution: Done


> Full Journal Compactation
> -------------------------
>
>                 Key: JBMESSAGING-1504
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1504
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>            Priority: Critical
>             Fix For: 2.0.0.beta4
>
>
> Let me describe how I think the compacting should work.
> Let's say we have a set of files in the journal:
> F0, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10
> min files is set to 10
> The current file is F6 and F7, F8, F9, F10 are unused files waiting to be used
> F0, F1, F2, F3, F4, F5 are files full of data and not open any more, however, data about their contents are stored in memory.
> We need a compacting thread that intermittently (say every 30 seconds) scans the set of journal files in memory.
> It scans F0... F5, and when it has completed that scan, it can decide which records are no longer needed in each file.
> A record is no longer needed in a file if it has already been deleted in any file F0.. F5.
> Once the scanner thread has computed which records are needed and which are not, it can compute a percentage of which records in total are dead space.
> E.g. the scanner might compute that 72% of the data in files F0.. .F5 are dead space.
> We then have a parameter that the user can configure compactorDeadSpaceThresholdPercentage, e.g. this might have a default of 75%.
> If the amount of dead space computed by the scanner >= compactorDeadSpaceThresholdPercentage, then the scanner will compact those files.
> The actual compacting approach goes as follows:
> The scanner knows how many new files it will need for the compacted records, let's say it needs two new files - it can get these from the unused files (e.g. F7, F8, F9 or F10) if they are available.
> It then opens the old files F0..F5 loads the wanted records into memory in blocks and copies them to the new files.
> When this process is finished it will end up with, say, two new files containing the compacted records.
> We can then save a marker file (empty in the journal directory) which says we are starting the rename.
> The old files F0..F5 then need to be renamed so they are no longer used by the journal (but can be recovered in case of a crash).
> Then the two new files need to be renamed so they will be picked up by the journal.
> When that process completes the marker file can be deleted.
> If the server crashes after renaming the old files but before renaming the new files, then the marker file will still exist in the journal. The journal can detect this on startup, and finish the process.
> This ensures the journal will still startup after such a crash.
> Also the JournalFile objects also need to be updated in memory when the compact is complete.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:49:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1427) Journal
	Cleanup
In-Reply-To: <6551971.1222785211162.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <487105437.1248450569266.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1427:
-----------------------------------------

    Issue Type: Feature Request  (was: Task)


> Journal Cleanup
> ---------------
>
>                 Key: JBMESSAGING-1427
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1427
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0 Alpha
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> If a destination is lazy, not consuming messages for a long time, the journal will grow until those messages are consumed.
> This would be a problem with DLQs or messages taking days before they are consumed.
> Since we inform the TransactionSummary on commits, we could change the journal to support multiple current-files based on configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:59:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 24 Jul 2009 11:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1877) Track the
 upgrades during EJB3 plugin 1.0.12 release
Message-ID: <515965219.1248451169196.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Track the upgrades during EJB3 plugin 1.0.12 release
----------------------------------------------------

                 Key: EJBTHREE-1877
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1877
             Project: EJB 3.0
          Issue Type: Task
          Components: plugin
            Reporter: jaikiran pai


Track changes during EJB3 plugin 1.0.12 release

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 11:59:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 24 Jul 2009 11:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1877) Track the
 upgrades during EJB3 plugin 1.0.12 release
In-Reply-To: <515965219.1248451169196.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <555166385.1248451169264.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned EJBTHREE-1877:
--------------------------------------

    Assignee: jaikiran pai


> Track the upgrades during EJB3 plugin 1.0.12 release
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1877
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1877
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: plugin
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> Track changes during EJB3 plugin 1.0.12 release

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 13:14:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Jul 2009 13:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7122) Handling of system
 properties in org.jboss.Main is inconsistent
Message-ID: <2048887591.1248455669283.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Handling of system properties in org.jboss.Main is inconsistent
---------------------------------------------------------------

                 Key: JBAS-7122
                 URL: https://jira.jboss.org/jira/browse/JBAS-7122
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-6.0.0.Alpha1


Main includes a Map<String, String> "props" which is used as a source of configuration information. In the Main constructor, this map is populated from the contents of the system properties. But during processCommandLine() any -D values are not added to the "props" map. Effect is adding something like -Djboss.bind.address=0.0.0.0 to JAVA_OPTS in run.conf works but passing it as a command line argument does not.

This is a minor issue; from the command line just use the command line switch that equates to the system property, e.g. -b 0.0.0.0

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 14:05:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Jul 2009 14:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7119) org.jboss.Main
 doesn't "fix" jgroups.bind_addr or java.rmi.server.hostname passed via
 JAVA_OPTS
In-Reply-To: <671760334.1248301229382.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <504479152.1248458729378.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated JBAS-7119:
-----------------------------------

        Summary: org.jboss.Main doesn't "fix" jgroups.bind_addr or java.rmi.server.hostname passed via JAVA_OPTS  (was: org.jboss.Main doesn't "fix" jgroups.bind_addr passed via JAVA_OPTS)
    Description: The logic to "fix" a jgroups.bind_addr and java.rmi.server.hostname values of 0.0.0.0 is only kicking in if the value is passed as an argument to org.jboss.Main. If the value is specified as part of JAVA_OPTS, it gets passed directly to java and doesn't get fixed.  (was: The logic to "fix" a jgroups.bind_addr value of 0.0.0.0 is only kicking in if the value is passed as an argument to org.jboss.Main. If the value is specified as part of JAVA_OPTS, it gets passed directly to java and doesn't get fixed.)


> org.jboss.Main doesn't "fix" jgroups.bind_addr or java.rmi.server.hostname passed via JAVA_OPTS
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7119
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7119
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The logic to "fix" a jgroups.bind_addr and java.rmi.server.hostname values of 0.0.0.0 is only kicking in if the value is passed as an argument to org.jboss.Main. If the value is specified as part of JAVA_OPTS, it gets passed directly to java and doesn't get fixed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 14:05:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Jul 2009 14:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7119) org.jboss.Main
 doesn't "fix" jgroups.bind_addr or java.rmi.server.hostname passed via
 JAVA_OPTS
In-Reply-To: <671760334.1248301229382.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1341986408.1248458729818.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7119.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


Fixed by separating out the "property fixing" logic from the loop through the command line arguments.

> org.jboss.Main doesn't "fix" jgroups.bind_addr or java.rmi.server.hostname passed via JAVA_OPTS
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7119
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7119
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The logic to "fix" a jgroups.bind_addr and java.rmi.server.hostname values of 0.0.0.0 is only kicking in if the value is passed as an argument to org.jboss.Main. If the value is specified as part of JAVA_OPTS, it gets passed directly to java and doesn't get fixed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 14:07:29 2009
From: jira-events at lists.jboss.org (Abdel Dridi (JIRA))
Date: Fri, 24 Jul 2009 14:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1691) JBM2 cluster
 fails under heavy load
Message-ID: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBM2 cluster fails under heavy load
-----------------------------------

                 Key: JBMESSAGING-1691
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Clustering
    Affects Versions: 2.0.0.beta4
         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
            Reporter: Abdel Dridi
            Assignee: Tim Fox
         Attachments: cluster-nodes-config-files.zip

I have a cluster of 2 nodes; A and B:
In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.

I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.

I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.

I faced the following issues:
Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
I also see "failed to accept connection: too many open files".

Let me know if you have any question,
Abdel


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 14:07:29 2009
From: jira-events at lists.jboss.org (Abdel Dridi (JIRA))
Date: Fri, 24 Jul 2009 14:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1691) JBM2 cluster
 fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1785860952.1248458849484.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Abdel Dridi updated JBMESSAGING-1691:
-------------------------------------

    Attachment: cluster-nodes-config-files.zip


config files for both cluster pairs (Live/Backup)

> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Tim Fox
>         Attachments: cluster-nodes-config-files.zip
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 14:09:29 2009
From: jira-events at lists.jboss.org (Abdel Dridi (JIRA))
Date: Fri, 24 Jul 2009 14:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1691) JBM2 cluster
 fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1864003653.1248458969303.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Abdel Dridi updated JBMESSAGING-1691:
-------------------------------------

    Attachment: Jbm2ClusterTest-NodeA.zip


> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Tim Fox
>         Attachments: cluster-nodes-config-files.zip, Jbm2ClusterTest-NodeA.zip, Jbm2ClusterTest-NodeB.zip
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 14:09:29 2009
From: jira-events at lists.jboss.org (Abdel Dridi (JIRA))
Date: Fri, 24 Jul 2009 14:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1691) JBM2 cluster
 fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1522226133.1248458969451.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Abdel Dridi updated JBMESSAGING-1691:
-------------------------------------

    Attachment: Jbm2ClusterTest-NodeB.zip


> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Tim Fox
>         Attachments: cluster-nodes-config-files.zip, Jbm2ClusterTest-NodeA.zip, Jbm2ClusterTest-NodeB.zip
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 14:14:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Jul 2009 14:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6847) JBoss MQ Topic and
 Queues deployed on both the servers in cluster.
In-Reply-To: <9360952.1241044307940.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1780000833.1248459269218.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477473#action_12477473 ] 

Brian Stansberry commented on JBAS-6847:
----------------------------------------

If you still see this with JBoss AS 5.0.0.GA or later, please open a thread in the clustering user forum at http://www.jboss.org/index.html?module=bb&op=viewforum&f=64

> JBoss MQ Topic and Queues deployed on both the servers in cluster.
> ------------------------------------------------------------------
>
>                 Key: JBAS-6847
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6847
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-4.2.2.GA
>         Environment: Server: JBoss AS 4.2.2.
> Components Used: HA Singleton, HA JBoss MQ, EJB 3.0
> JVM: 96GB Virtual Memory, Concurrent Garbage Collection algorithm.
> Cluster: 2 servers connected with TCPPING mechanism.
>            Reporter: Gideon Raj
>            Assignee: Brian Stansberry
>
> When both the servers are up and running, one pause (either cause by a GC or a network glitch) causes server2 to start the HA Singleton object and also bind the JMS Queues and Topics. At this point both the servers are running as primaries.
> (Note regarding the pause: We are monitoring the GC collections using JConsole. Only the ParNew collections have taken place, the ConcurrentMarkSweep collection has not yet taken place).
> After a couple of minutes, both the servers communicate, and server1 reestablishes as the sole primary in the cluster. But the HA Singleton, JMS Queues and Topics created in server2 remains and is not unbound. 
> The sequence of events:
> Log message from server1:
> 2009-04-22 17:16:11,251 org.jgroups.blocks.BasicConnectionTable$Connection._send(BasicConnectionTable.java:443) WARN  [org.jgroups.blocks.ConnectionTable] peer closed connection, trying to re-send msg
> 2009-04-22 17:16:11,252 org.jgroups.blocks.BasicConnectionTable$Connection._send(BasicConnectionTable.java:449) ERROR [org.jgroups.blocks.ConnectionTable] 2nd attempt to send data failed too
> Log message from server2
> 2009-04-22 17:15:42,828 org.jboss.ha.framework.server.HAPartitionImpl.suspect(HAPartitionImpl.java:584) INFO  [org.jboss.ha.framework.interfaces.HAPartition.CUSTOMPartition] Suspected member: server1:7800
> ....
> 2009-04-22 17:15:42,940 org.jboss.ha.framework.server.DistributedReplicantManagerImpl.membershipChanged(DistributedReplicantManagerImpl.java:374) INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.CUSTOMPartition] Dead members: 1 ([server1:1199])
> 2009-04-22 17:15:42,941 org.jboss.ha.framework.server.DistributedReplicantManagerImpl.membershipChanged(DistributedReplicantManagerImpl.java:375) INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.CUSTOMPartition] New Members : 0 ([])
> 2009-04-22 17:15:42,941 org.jboss.ha.framework.server.DistributedReplicantManagerImpl.membershipChanged(DistributedReplicantManagerImpl.java:376) INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.CUSTOMPartition] All Members : 1 ([server2:1199])
> .....
> 2009-04-22 17:16:11,255 org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:668) WARN  [org.jgroups.protocols.pbcast.NAKACK] server2:49665] discarded message from non-member server1:57210, my view is [server2:49665|2] [server2:49665]
> 2009-04-22 17:16:11,259 org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:668) WARN  [org.jgroups.protocols.pbcast.NAKACK] server2:49663] discarded message from non-member server1:57208, my view is [server2:49663|2] [server2:49663]
> .....
> 2009-04-22 17:16:13,877 org.jboss.cache.TreeCache.viewAccepted(TreeCache.java:5687) INFO  [org.jboss.cache.TreeCache] viewAccepted(): [server2:49663|3] [server2:49663, server1:57824]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 15:47:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Jul 2009 15:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-535) Move task
 configuration in server-config.xml into a target
In-Reply-To: <1701874410.1247777909261.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1174815178.1248464849313.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier closed JBBUILD-535.
-----------------------------

    Resolution: Done


Moved the task defs and server configs into a target.

> Move task configuration in server-config.xml into a target
> ----------------------------------------------------------
>
>                 Key: JBBUILD-535
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-535
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the task definitions in server-config.xml are not inside a target.  This means that they can't depend on another target to define their path references.  This should be changed so that everything is done inside targets.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 15:49:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Jul 2009 15:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-531) Remove testsuite
 dependency on libraries.ent
In-Reply-To: <6026725.1243637396349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <253053500.1248464969191.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier closed JBBUILD-531.
-----------------------------

    Resolution: Done


The testsuite no longer uses libraries.ent

> Remove testsuite dependency on libraries.ent
> --------------------------------------------
>
>                 Key: JBBUILD-531
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-531
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the testsuite uses the jars in thirdparty via the file libraries.ent.  Instead the paths in the testsuite should directly reference jars in the local maven repository directory.  This can be done by building the paths with the maven ant tasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 15:51:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Jul 2009 15:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-537) Improved target
	dependency tree
In-Reply-To: <1059955584.1248374669143.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <960017059.1248465089147.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-537:
------------------------------

        Summary: Improved target dependency tree  (was: Use target dependencies instead of antcall to avoid duplicate target invocations)
    Description: 
There are still a lot of tasks that are outside of any target.  Eventually, all tasks should be in targets.

There are a lot of <antcall> in the testsuite.  Each antcall creates a new ant project instance and invokes all the dependencies of the invoked target.  This causes certain initialization targets to be run several times.  Possibly this could be improved using either standard target dependencies, or using something like <runltarget> from the antcontrib tasks.

  was:There are currently a lot of <antcall> in the testsuite.  Each antcall creates a new ant project instance and invokes all the dependencies of the invoked target.  Possibly this could be improved using either standard target dependencies, or using something like <calltarget> from the antcontrib tasks.



> Improved target dependency tree
> -------------------------------
>
>                 Key: JBBUILD-537
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-537
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> There are still a lot of tasks that are outside of any target.  Eventually, all tasks should be in targets.
> There are a lot of <antcall> in the testsuite.  Each antcall creates a new ant project instance and invokes all the dependencies of the invoked target.  This causes certain initialization targets to be run several times.  Possibly this could be improved using either standard target dependencies, or using something like <runltarget> from the antcontrib tasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 15:53:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Jul 2009 15:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-539) Switch dependency
 resolution to use a pom in testsuite instead of in thirdparty.
Message-ID: <198920888.1248465209185.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Switch dependency resolution to use a pom in testsuite instead of in thirdparty.
--------------------------------------------------------------------------------

                 Key: JBBUILD-539
                 URL: https://jira.jboss.org/jira/browse/JBBUILD-539
             Project: JBoss Build System
          Issue Type: Sub-task
            Reporter: Paul Gier
            Assignee: Paul Gier




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 15:57:41 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Jul 2009 15:57:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-540) Review notes from
 testsuite refactoring
Message-ID: <68510224.1248465461370.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Review notes from testsuite refactoring
---------------------------------------

                 Key: JBBUILD-540
                 URL: https://jira.jboss.org/jira/browse/JBBUILD-540
             Project: JBoss Build System
          Issue Type: Task
            Reporter: Paul Gier
            Assignee: Paul Gier
             Fix For: Maven Build - App Server (Phase 3)
         Attachments: dependency_notes.txt

I kept some notes related to dependencies while refactoring the testsuite build.  There are some dependencies that might be removed or improved in some way.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 15:57:41 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Jul 2009 15:57:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-540) Review notes from
 testsuite refactoring
In-Reply-To: <68510224.1248465461370.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <471104938.1248465461466.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-540:
------------------------------

    Attachment: dependency_notes.txt


> Review notes from testsuite refactoring
> ---------------------------------------
>
>                 Key: JBBUILD-540
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-540
>             Project: JBoss Build System
>          Issue Type: Task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>         Attachments: dependency_notes.txt
>
>
> I kept some notes related to dependencies while refactoring the testsuite build.  There are some dependencies that might be removed or improved in some way.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 16:02:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Jul 2009 16:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-539) Switch dependency
 resolution to use a pom in dist or testsuite instead of in thirdparty.
In-Reply-To: <198920888.1248465209185.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <239756829.1248465749115.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-539:
------------------------------

    Summary: Switch dependency resolution to use a pom in dist or testsuite instead of in thirdparty.  (was: Switch dependency resolution to use a pom in testsuite instead of in thirdparty.)


> Switch dependency resolution to use a pom in dist or testsuite instead of in thirdparty.
> ----------------------------------------------------------------------------------------
>
>                 Key: JBBUILD-539
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-539
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 17:00:42 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 24 Jul 2009 17:00:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-1077) Fix problem in
 CompressingMarshaller
In-Reply-To: <21329107.1230710934327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <620947764.1248469242556.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBREM-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ron Sigal updated JBREM-1077:
-----------------------------

    Fix Version/s: 2.5.2 (Flounder)


> Fix problem in CompressingMarshaller
> ------------------------------------
>
>                 Key: JBREM-1077
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1077
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11
>            Reporter: Ron Sigal
>            Assignee: Ron Sigal
>             Fix For: 2.5.2 (Flounder), 2.2.3.SP1
>
>         Attachments: CompressionInvokerMarshaller.java, CompressionInvokerUnmarshaller.java
>
>
> In org.jboss.remoting.marshal.compress.CompressingMarshaller.write(),
>       gzos.finish();
>       oos.flush();
> should be
>       oos.flush();
>       bos.flush();
>       gzos.flush();
>       gzos.finish();
> as it is on the 2.x branch.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 17:07:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Jul 2009 17:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-539) Switch dependency
 resolution to use poms in dist and testsuite instead of in thirdparty.
In-Reply-To: <198920888.1248465209185.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1280056612.1248469649101.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-539:
------------------------------

    Summary: Switch dependency resolution to use poms in dist and testsuite instead of in thirdparty.  (was: Switch dependency resolution to use a pom in dist or testsuite instead of in thirdparty.)


> Switch dependency resolution to use poms in dist and testsuite instead of in thirdparty.
> ----------------------------------------------------------------------------------------
>
>                 Key: JBBUILD-539
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-539
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 24 21:06:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 24 Jul 2009 21:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1877) Track the
 upgrades during EJB3 plugin 1.0.12 release
In-Reply-To: <515965219.1248451169196.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1539333479.1248483989219.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1877.
------------------------------------

                  Resolution: Done
    Component Fix Version(s): jboss-ejb3-plugin:1.0.12


> Track the upgrades during EJB3 plugin 1.0.12 release
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1877
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1877
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: plugin
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> Track changes during EJB3 plugin 1.0.12 release

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 25 00:15:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 25 Jul 2009 00:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7123) JBossCacheManager
 remains open to requests after shutdown
Message-ID: <721981088.1248495329189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBossCacheManager remains open to requests after shutdown
---------------------------------------------------------

                 Key: JBAS-7123
                 URL: https://jira.jboss.org/jira/browse/JBAS-7123
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering, Web (Tomcat) service
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


The work Paul Ferraro did with LockValve ensures that typically application activity cannot reach the clustered session manager after its stop() processing executes, but testing is showing the StandardHostValve can end up causing calls to findSession that end up blowing up with an NPE.  That's the specific issue; in general, the methods in the Manager API need to be hardened to react properly if invoked during/after shutdown.

Solution is to use the same semaphore that LockValve uses, but use it internally -- add tryLock/release calls around the relevant code. Once stop() processing proceeds, tryLock will fail and the methods can react appropriately.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 25 10:51:29 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Sat, 25 Jul 2009 10:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7047) Deployers hide
 exception cause stack
In-Reply-To: <6579847.1245767156834.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1786491922.1248533489480.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pete Muir updated JBAS-7047:
----------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
         Assignee: Ales Justin
         Priority: Critical  (was: Major)


Schedule and assign to Ales, we need this to pass the CDI TCK.

> Deployers hide exception cause stack
> ------------------------------------
>
>                 Key: JBAS-7047
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7047
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Pete Muir
>            Assignee: Ales Justin
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Currently the deployers unwrap all deployment exceptions to the root cause, and store in incompleteDeployments. This means we can't check for exception wrapping

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 26 07:50:29 2009
From: jira-events at lists.jboss.org (Luca Stancapiano (JIRA))
Date: Sun, 26 Jul 2009 07:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-287) active duration
 field creating a new topic
Message-ID: <344391334.1248609029434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

active duration field creating a new topic
------------------------------------------

                 Key: JBFORUMS-287
                 URL: https://jira.jboss.org/jira/browse/JBFORUMS-287
             Project: JBoss Forums
          Issue Type: Bug
    Affects Versions: 1.2.0 Alpha
         Environment: JBoss Portal 2.7.2 with JBoss AS 4.2.3.GA
            Reporter: Luca Stancapiano
            Assignee: Luca Stancapiano
             Fix For: 1.2.0 Alpha, 1.3.0 Alpha, 1.2.0 GA


when I create a new topic I have an error of conversion. The active duration field is an Integer but it is stored as String because the converter doesn't work right:

org.jboss.portlet.forums.ui.action.converters.PollDurationConverter:

   public Object getAsObject(FacesContext context, UIComponent component, String value) throws ConverterException
    {
        
        if (value==null || value.trim().length()==0)
        {
            return 0;
        }
        else
        {
            try
            {
            	return value;
            }
            catch (NumberFormatException e)
            {
                FacesMessage message = new FacesMessage();
                message.setDetail(JSFUtil.getBundleMessage(Constants.BUNDLE_NAME, ValidatorMessages.POLL_DURATION_MSG));
                message.setSummary(JSFUtil.getBundleMessage(Constants.BUNDLE_NAME, ValidatorMessages.POLL_DURATION_MSG));
                message.setSeverity(FacesMessage.SEVERITY_ERROR);
                throw new ConverterException(message);
            }
        }
    }


It should return return Integer.valueOf(value);

because the result is elaborated by the method setActiveDuration(int intactiveDuration)   of org.jboss.portlet.forums.ui.action.PostAction class


It should to be tested in other versions too

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 26 16:13:29 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Sun, 26 Jul 2009 16:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-743) Support annotation
 introduction to interfaces
Message-ID: <524496978.1248639209321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Support annotation introduction to interfaces
---------------------------------------------

                 Key: JBAOP-743
                 URL: https://jira.jboss.org/jira/browse/JBAOP-743
             Project: JBoss AOP
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Flavia Rainone


JBoss AOP should support annotation introductions to interfaces. Currently, annotations can be introduced to classes only.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 26 17:53:29 2009
From: jira-events at lists.jboss.org (Luca Stancapiano (JIRA))
Date: Sun, 26 Jul 2009 17:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-287) active duration
 field creating a new topic
In-Reply-To: <344391334.1248609029434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1469143657.1248645209126.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBFORUMS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luca Stancapiano resolved JBFORUMS-287.
---------------------------------------

    Resolution: Done


done

> active duration field creating a new topic
> ------------------------------------------
>
>                 Key: JBFORUMS-287
>                 URL: https://jira.jboss.org/jira/browse/JBFORUMS-287
>             Project: JBoss Forums
>          Issue Type: Bug
>    Affects Versions: 1.2.0 Alpha
>         Environment: JBoss Portal 2.7.2 with JBoss AS 4.2.3.GA
>            Reporter: Luca Stancapiano
>            Assignee: Luca Stancapiano
>             Fix For: 1.2.0 Alpha, 1.3.0 Alpha, 1.2.0 GA
>
>
> when I create a new topic I have an error of conversion. The active duration field is an Integer but it is stored as String because the converter doesn't work right:
> org.jboss.portlet.forums.ui.action.converters.PollDurationConverter:
>    public Object getAsObject(FacesContext context, UIComponent component, String value) throws ConverterException
>     {
>         
>         if (value==null || value.trim().length()==0)
>         {
>             return 0;
>         }
>         else
>         {
>             try
>             {
>             	return value;
>             }
>             catch (NumberFormatException e)
>             {
>                 FacesMessage message = new FacesMessage();
>                 message.setDetail(JSFUtil.getBundleMessage(Constants.BUNDLE_NAME, ValidatorMessages.POLL_DURATION_MSG));
>                 message.setSummary(JSFUtil.getBundleMessage(Constants.BUNDLE_NAME, ValidatorMessages.POLL_DURATION_MSG));
>                 message.setSeverity(FacesMessage.SEVERITY_ERROR);
>                 throw new ConverterException(message);
>             }
>         }
>     }
> It should return return Integer.valueOf(value);
> because the result is elaborated by the method setActiveDuration(int intactiveDuration)   of org.jboss.portlet.forums.ui.action.PostAction class
> It should to be tested in other versions too

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 01:19:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 27 Jul 2009 01:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-142) SP Post Form
 Authenticator that can handle signatures
In-Reply-To: <356609847.1248362549083.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1757454054.1248671969380.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-142:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha5
                       (was: IDFED-1.0.0.beta1)


> SP Post Form Authenticator that can handle signatures
> -----------------------------------------------------
>
>                 Key: JBID-142
>                 URL: https://jira.jboss.org/jira/browse/JBID-142
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> Currently we do not have a form authenticator doing POST on the SP end that can handle signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 01:19:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 27 Jul 2009 01:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-142) SP Post Form
 Authenticator that can handle signatures
In-Reply-To: <356609847.1248362549083.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <335668009.1248671969495.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-142.
------------------------------

    Resolution: Done


> SP Post Form Authenticator that can handle signatures
> -----------------------------------------------------
>
>                 Key: JBID-142
>                 URL: https://jira.jboss.org/jira/browse/JBID-142
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> Currently we do not have a form authenticator doing POST on the SP end that can handle signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 04:01:29 2009
From: jira-events at lists.jboss.org (Max Rydahl Andersen (JIRA))
Date: Mon, 27 Jul 2009 04:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7103) Hot deployment
 woks incorrectly on the EE project without deployment descriptors
In-Reply-To: <1370254810.1247736869351.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1915826911.1248681689399.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477585#action_12477585 ] 

Max Rydahl Andersen commented on JBAS-7103:
-------------------------------------------

This is actually a rather big usability issue ;(

Any chance touching the root directory could be made an alternative option for restarting the module ?

> Hot deployment woks incorrectly on the EE project without deployment descriptors
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-7103
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7103
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: Windows XP SP3 
> JBoss AS: 5.0.1.GA
> Eclipse 3.5: eclipse-jee-galileo-win32.zip 
> JBossTools : 3.0.1.GA JBossTools-ALL-win32-3.0.1.GA-R200905070146-H18.zip 
>            Reporter: Alexander Lengson
>            Assignee: Ales Justin
>
> JBoss AS 5.0.1.GA does not redeploy new EJB written over old one when EJB JAR does not contain deployment descriptors and EJB is deployed as an exploded folder, not single-file archive.
> As discussed in another issue (https://jira.jboss.org/jira/browse/JBIDE-4608), this is because of JBoss AS redeploys EJB if its descriptor is touched. Simple changing .class file is not enough to make JBoss redeploy the EJB, but in the case when there is no deployment descriptor (everything is configured via annotations), nothing may cause redeploy (except full remove and new publish)
> Workaround is to have deployment descriptors in the module.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 05:09:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 27 Jul 2009 05:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-357) Error while
 validating jPDL file: Problem class was moved from API
In-Reply-To: <985295068.1247498249570.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1161835969.1248685769438.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-357.
---------------------------

    Resolution: Done


The validation is also performed automatically when the file is saved. If more sophisticated (i.e. real background) validation is needed a new issue should be created.

> Error while validating jPDL file: Problem class was moved from API
> ------------------------------------------------------------------
>
>                 Key: GPD-357
>                 URL: https://jira.jboss.org/jira/browse/GPD-357
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM jPDL Designer 4.0.0.GA
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.1
>
>
> 1) Fix the dynamic loading problem of the problem class that has moved
> 2) Add automatic validation activation in the background

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 06:16:29 2009
From: jira-events at lists.jboss.org (Alexander Lengson (JIRA))
Date: Mon, 27 Jul 2009 06:16:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBASMP-21) Maven integration
 issues: setting facets on maven projects and deploying ear on JBoss
Message-ID: <895686066.1248689789366.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Maven integration issues: setting facets on maven projects and deploying ear on JBoss
-------------------------------------------------------------------------------------

                 Key: JBASMP-21
                 URL: https://jira.jboss.org/jira/browse/JBASMP-21
             Project: JBoss AS Maven Plugins
          Issue Type: Bug
         Environment: Eclipse 3.5 
m2eclipse (0.9.9.20090720)
JBoss Tools AS M3 developer version
Subclipse SVN plugin 1.6.3
            Reporter: Alexander Lengson
            Assignee: Andrew Lee Rubinger



Using Maven command line, I created four projects:
container - the parent Maven project. It also serves as a container for other projects
prj-jar - a shared library used by all other EJBs
prj-ejb - sample EJB
prj-ear - EE container for jar and ejb

Apache plugins for Maven (both for ejb and ear) are used. 

I've performed the following steps:
* imported container into SVN
* opened Eclipse 3.5 with M3 JBoss AS Tools and dev version of m2eclipse (0.9.9.20090720)
* right-clicked on container and chosen "Checkout as Maven project"
* waited for the process to be finished

And the following likely are bugs and/or open questions:
* for prj-jar: 0.0.1-SNAPSHOT "JBoss Maven Integration" facet is not checked. After checking further configuration suggests "0.0.1-SNAPSHOT" instead of "1.0-SNAPSHOT" as declared in pom.xml already.
* for prj-ejb: the same, i.e. 0.0.1-SNAPSHOT "JBoss Maven Integration" facet is not checked. After checking further configuration suggests "0.0.1-SNAPSHOT" instead of "1.0-SNAPSHOT" as declared in pom.xml already.
* for prj-ear: the same.
* for container: "JBoss Maven Integration" facet is not set and can not be selected. What another facet should be set to meet requirements?
* for prj-ejb: there is no Project Facet checked at all.
* for prj-ejb: when I check EJB 3.0 and then click Further Configuration, it does not propose sensible defaults (instead they are as always: src for sources, build/classes for compiled)
* for prj-ejb: If I provided values for src and build folder mistakenly, it does not allow to change them (even uncheck/check again shows only form with all fields greyed)
* for prj-ejb: after checking Java 6.0 and EJB 3.0, there are still errors in Problems View:
	EJB Module 3.0 requires Java 5.0 or newer.	prj-ejb		line 1	Maven Problem --- disappears after Eclipse restart
	One or more constraints have not been satisfied.	prj-ejb		line 1	Maven Problem --- disappears after Eclipse restart
	Java compiler level does not match the version of the installed Java project facet.	prj-ejb		Unknown	Faceted Project Problem (Java Version Mismatch) --- survives Eclipse restart
* for prj-ear: Java EE module dependencies are not checked (they may be suggested from the pom.xml) 
* for prj-ear: Maven plugin maven-ear-plugin has the option to put all referenced libraries into Lib directory:
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-ear-plugin</artifactId>
				<version>2.3.2</version>
				<configuration>
					<includeLibInApplicationXml>true</includeLibInApplicationXml>
					...
		That builds the EAR which contains lib/ folder inside and all references libs like:
	drools-api-5.0.1.jar
	drools-core-5.0.1.jar
	hsqldb-1.8.0.10.jar
	joda-time-1.6.jar
	mvel2-2.0.10.jar
	prj-jar-1.0-SNAPSHOT.jar

	That can be assured by running command:
	container>mvn install

	Eclipse does not put those libraries into deploy dir while making "Full Publish" which causes server startup errors.
	It's reasonable to copy these libraries onto server when using JBoss Server View and debugging server from Eclipse.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 07:13:29 2009
From: jira-events at lists.jboss.org (Alexander Lengson (JIRA))
Date: Mon, 27 Jul 2009 07:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBASMP-21) Maven integration
 issues: setting facets on maven projects and deploying ear on JBoss
In-Reply-To: <895686066.1248689789366.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1260765567.1248693209213.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBASMP-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Lengson updated JBASMP-21:
------------------------------------

    Attachment: container.zip


container - the parent Maven project. It also serves as a container for other projects
prj-jar - a shared library used by all other EJBs
prj-ejb - sample EJB
prj-ear - EE container for jar and ejb

> Maven integration issues: setting facets on maven projects and deploying ear on JBoss
> -------------------------------------------------------------------------------------
>
>                 Key: JBASMP-21
>                 URL: https://jira.jboss.org/jira/browse/JBASMP-21
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>         Environment: Eclipse 3.5 
> m2eclipse (0.9.9.20090720)
> JBoss Tools AS M3 developer version
> Subclipse SVN plugin 1.6.3
>            Reporter: Alexander Lengson
>            Assignee: Andrew Lee Rubinger
>         Attachments: container.zip
>
>
> Using Maven command line, I created four projects:
> container - the parent Maven project. It also serves as a container for other projects
> prj-jar - a shared library used by all other EJBs
> prj-ejb - sample EJB
> prj-ear - EE container for jar and ejb
> Apache plugins for Maven (both for ejb and ear) are used. 
> I've performed the following steps:
> * imported container into SVN
> * opened Eclipse 3.5 with M3 JBoss AS Tools and dev version of m2eclipse (0.9.9.20090720)
> * right-clicked on container and chosen "Checkout as Maven project"
> * waited for the process to be finished
> And the following likely are bugs and/or open questions:
> * for prj-jar: 0.0.1-SNAPSHOT "JBoss Maven Integration" facet is not checked. After checking further configuration suggests "0.0.1-SNAPSHOT" instead of "1.0-SNAPSHOT" as declared in pom.xml already.
> * for prj-ejb: the same, i.e. 0.0.1-SNAPSHOT "JBoss Maven Integration" facet is not checked. After checking further configuration suggests "0.0.1-SNAPSHOT" instead of "1.0-SNAPSHOT" as declared in pom.xml already.
> * for prj-ear: the same.
> * for container: "JBoss Maven Integration" facet is not set and can not be selected. What another facet should be set to meet requirements?
> * for prj-ejb: there is no Project Facet checked at all.
> * for prj-ejb: when I check EJB 3.0 and then click Further Configuration, it does not propose sensible defaults (instead they are as always: src for sources, build/classes for compiled)
> * for prj-ejb: If I provided values for src and build folder mistakenly, it does not allow to change them (even uncheck/check again shows only form with all fields greyed)
> * for prj-ejb: after checking Java 6.0 and EJB 3.0, there are still errors in Problems View:
> 	EJB Module 3.0 requires Java 5.0 or newer.	prj-ejb		line 1	Maven Problem --- disappears after Eclipse restart
> 	One or more constraints have not been satisfied.	prj-ejb		line 1	Maven Problem --- disappears after Eclipse restart
> 	Java compiler level does not match the version of the installed Java project facet.	prj-ejb		Unknown	Faceted Project Problem (Java Version Mismatch) --- survives Eclipse restart
> * for prj-ear: Java EE module dependencies are not checked (they may be suggested from the pom.xml) 
> * for prj-ear: Maven plugin maven-ear-plugin has the option to put all referenced libraries into Lib directory:
> 				<groupId>org.apache.maven.plugins</groupId>
> 				<artifactId>maven-ear-plugin</artifactId>
> 				<version>2.3.2</version>
> 				<configuration>
> 					<includeLibInApplicationXml>true</includeLibInApplicationXml>
> 					...
> 		That builds the EAR which contains lib/ folder inside and all references libs like:
> 	drools-api-5.0.1.jar
> 	drools-core-5.0.1.jar
> 	hsqldb-1.8.0.10.jar
> 	joda-time-1.6.jar
> 	mvel2-2.0.10.jar
> 	prj-jar-1.0-SNAPSHOT.jar
> 	That can be assured by running command:
> 	container>mvn install
> 	Eclipse does not put those libraries into deploy dir while making "Full Publish" which causes server startup errors.
> 	It's reasonable to copy these libraries onto server when using JBoss Server View and debugging server from Eclipse.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 08:34:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 27 Jul 2009 08:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <436059512.1248698069454.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477621#action_12477621 ] 

Richard Achmatowicz commented on JGRP-1011:
-------------------------------------------

Uploaded to SourceForge. 
They have changed their web interface and uploading mechanism considerably. You now add release notes by selecting the file in question and right-clicking. 


> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>         Attachments: JGroups_2_6_11_GA_reports.zip
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 08:36:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 27 Jul 2009 08:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-1011) Release JGroups 2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2049525716.1248698189129.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz closed JGRP-1011.
-------------------------------------

    Resolution: Done


> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>         Attachments: JGroups_2_6_11_GA_reports.zip
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 09:13:29 2009
From: jira-events at lists.jboss.org (Max Rydahl Andersen (JIRA))
Date: Mon, 27 Jul 2009 09:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-534) Maven repository
	aggregation
In-Reply-To: <1192295848.1247639309938.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1108920619.1248700409664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477624#action_12477624 ] 

Max Rydahl Andersen commented on JBBUILD-534:
---------------------------------------------

"* the transitive enclosure of information for (groupId+artifactId+version+classifier) should be equal independent of the repo where you get the artifact from "

unfortunately that does not fit well with the current business model of a split....something gotta give...any suggestions ?

> Maven repository aggregation
> ----------------------------
>
>                 Key: JBBUILD-534
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-534
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Thomas Diesler
>
> There are a number of projects which have dependencies on non-jboss
> maven repos (jboss-osgi is one of them)
> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235779#4235779
> I believe, this issue is general enough to have proper repo aggregation 
> setup somehow
> Here is a link to some aggregators
> http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix
> Is this a way you want to move forward or should we stick with manually copying individual artefacts to the jboss repo? 
> Please note, that by doing so (i.e. mvn deploy-file) you loose the original pom and hence the information on transitive dependencies.
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 09:26:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Mon, 27 Jul 2009 09:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-534) Maven repository
	aggregation
In-Reply-To: <1192295848.1247639309938.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1564709938.1248701189295.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477628#action_12477628 ] 

Paul Gier commented on JBBUILD-534:
-----------------------------------

There was some discussion on the maven developers list about repository synching, and how we can manage synchronization with our dependencies on rebuilt stuff (for example all the jars with "-brew" at the end).  We can't send them to the central repository because they are not our upstream projects, but we need them for building projects like the app server.  So it doesn't really do us any good to synchronize the jboss app server jars to central if we can't also send the dependencies.  So the recommendation is to change the groupId of our rebuilt artifacts and prefix it with something like "org.jboss".  If we use a groupId like this then we could avoid conflicts caused by rebuilt artifacts.  But this would cause other problems [1].

[1]http://www.nabble.com/Depending-on-Artifacts-not-in-central-td24394458.html

> Maven repository aggregation
> ----------------------------
>
>                 Key: JBBUILD-534
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-534
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Thomas Diesler
>
> There are a number of projects which have dependencies on non-jboss
> maven repos (jboss-osgi is one of them)
> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235779#4235779
> I believe, this issue is general enough to have proper repo aggregation 
> setup somehow
> Here is a link to some aggregators
> http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix
> Is this a way you want to move forward or should we stick with manually copying individual artefacts to the jboss repo? 
> Please note, that by doing so (i.e. mvn deploy-file) you loose the original pom and hence the information on transitive dependencies.
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 09:46:29 2009
From: jira-events at lists.jboss.org (Max Rydahl Andersen (JIRA))
Date: Mon, 27 Jul 2009 09:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-534) Maven repository
	aggregation
In-Reply-To: <1192295848.1247639309938.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <698373512.1248702389526.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477639#action_12477639 ] 

Max Rydahl Andersen commented on JBBUILD-534:
---------------------------------------------

yes - exactly, its not really solvable if product binaries are considered different.
Then the dependency set will have to be different for both project and product builds which will lead to horrible maintanence headache ;(

> Maven repository aggregation
> ----------------------------
>
>                 Key: JBBUILD-534
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-534
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Thomas Diesler
>
> There are a number of projects which have dependencies on non-jboss
> maven repos (jboss-osgi is one of them)
> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235779#4235779
> I believe, this issue is general enough to have proper repo aggregation 
> setup somehow
> Here is a link to some aggregators
> http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix
> Is this a way you want to move forward or should we stick with manually copying individual artefacts to the jboss repo? 
> Please note, that by doing so (i.e. mvn deploy-file) you loose the original pom and hence the information on transitive dependencies.
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 10:49:40 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 27 Jul 2009 10:49:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7124)
 org.jboss.security.ssl.DomainSocketFactory to override zero-argument
 javax.net.SocketFactory.createSocket()
Message-ID: <1257933592.1248706180664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

org.jboss.security.ssl.DomainSocketFactory to override zero-argument javax.net.SocketFactory.createSocket()
-----------------------------------------------------------------------------------------------------------

                 Key: JBAS-7124
                 URL: https://jira.jboss.org/jira/browse/JBAS-7124
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Juergen none
            Assignee: Anil Saldhana


I use org.jboss.security.ssl.DomainSocketFactory but need to call parameterless createSocket()

this method is not overridden in DomainSocketFactory, so initSSLContext(), setNeedClientAuth(), etc. does not happen.

could you implement org.jboss.security.ssl.DomainSocketFactory.createSocket() ?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 11:14:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 27 Jul 2009 11:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1692)
 symmetric-cluster example fails on a multi-core machine
Message-ID: <1737804129.1248707669208.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

symmetric-cluster example fails on a multi-core machine
-------------------------------------------------------

                 Key: JBMESSAGING-1692
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1692
             Project: JBoss Messaging
          Issue Type: Task
    Affects Versions: 2.0.0.beta4, 2.0.0.beta3, 2.0.0.beta2
            Reporter: Clebert Suconic
            Assignee: Tim Fox
             Fix For: 2.0.0




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 11:44:41 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Mon, 27 Jul 2009 11:44:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-537) Improved Ant
 target dependency hierarchy for building
In-Reply-To: <1059955584.1248374669143.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2102610349.1248709481790.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-537:
------------------------------

    Summary: Improved Ant target dependency hierarchy for building  (was: Improved target dependency tree)


> Improved Ant target dependency hierarchy for building
> -----------------------------------------------------
>
>                 Key: JBBUILD-537
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-537
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> There are still a lot of tasks that are outside of any target.  Eventually, all tasks should be in targets.
> There are a lot of <antcall> in the testsuite.  Each antcall creates a new ant project instance and invokes all the dependencies of the invoked target.  This causes certain initialization targets to be run several times.  Possibly this could be improved using either standard target dependencies, or using something like <runltarget> from the antcontrib tasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 11:46:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Mon, 27 Jul 2009 11:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-540) Review notes from
 testsuite refactoring
In-Reply-To: <68510224.1248465461370.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <258224337.1248709589279.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-540:
------------------------------

        Parent: JBBUILD-529
    Issue Type: Sub-task  (was: Task)


> Review notes from testsuite refactoring
> ---------------------------------------
>
>                 Key: JBBUILD-540
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-540
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>         Attachments: dependency_notes.txt
>
>
> I kept some notes related to dependencies while refactoring the testsuite build.  There are some dependencies that might be removed or improved in some way.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 11:46:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Mon, 27 Jul 2009 11:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-540) Review dependency
 notes from testsuite refactoring and clean up AS dependency tree
In-Reply-To: <68510224.1248465461370.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1570463911.1248709589326.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-540:
------------------------------

        Summary: Review dependency notes from testsuite refactoring and clean up AS dependency tree  (was: Review notes from testsuite refactoring)
    Description: I am keeping notes related to dependencies while refactoring the testsuite build.  There are some dependencies that might be removed or reorganized in a better way.  (was: I kept some notes related to dependencies while refactoring the testsuite build.  There are some dependencies that might be removed or improved in some way.)


> Review dependency notes from testsuite refactoring and clean up AS dependency tree
> ----------------------------------------------------------------------------------
>
>                 Key: JBBUILD-540
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-540
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>         Attachments: dependency_notes.txt
>
>
> I am keeping notes related to dependencies while refactoring the testsuite build.  There are some dependencies that might be removed or reorganized in a better way.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 11:52:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 27 Jul 2009 11:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBAS-7125) JMS Destinations:
 properties "Count" and "Time Last Update" are 0 after sending a message
Message-ID: <303504614.1248709949471.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer moved EMBJOPR-206 to JBAS-7125:
--------------------------------------------

     Project: JBoss Application Server  (was: Embedded Jopr)
         Key: JBAS-7125  (was: EMBJOPR-206)
    Security: Public


> JMS Destinations: properties "Count" and "Time Last Update" are 0 after sending a message
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-7125
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7125
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Tests:
> testQueueMetrics*
> testTopicMetrics*
>            Reporter: Ondrej ?i?ka
>
> After sending a message(s), the some properties have bad values:
> Count = 0,
> Count Delta = 0,
> Time Last Update = 0,
> However, 
> Depth	4	The current message count of pending messages within the queue waiting for dispatch
> Depth Delta	3	The message count delta of pending messages since last method call
> Did the meaning of  Count change?
> I've looked at the queue MBean in JMX console, and there's no count property. Jopr takes this from ProfilseService, so perhaps that's where zero comes from? Anyway, this is a regression.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 27 11:54:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 27 Jul 2009 11:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7125) JMS Destinations:
 properties "Count" and "Time Last Update" are 0 after sending a message
Message-ID: <925954164.1248710069234.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7125:
-------------------------------

          Component/s: JMS (JBoss Messaging)
                       ProfileService
        Fix Version/s: JBossAS-5.2.0.Beta1
    Affects Version/s: JBossAS-5.1.0.GA
             Assignee: Scott M Stark


Scott, this one sounds like either a JBoss Messaging, or a PS MO, bug. Would you take a look?


> JMS Destinations: properties "Count" and "Time Last Update" are 0 after sending a message
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-7125
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7125
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging), ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Tests:
> testQueueMetrics*
> testTopicMetrics*
>            Reporter: Ondrej ?i?ka
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> After sending a message(s), the some properties have bad values:
> Count = 0,
> Count Delta = 0,
> Time Last Update = 0,
> However, 
> Depth	4	The current message count of pending messages within the queue waiting for dispatch
> Depth Delta	3	The message count delta of pending messages since last method call
> Did the meaning of  Count change?
> I've looked at the queue MBean in JMX console, and there's no count property. Jopr takes this from ProfilseService, so perhaps that's where zero comes from? Anyway, this is a regression.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 27 11:54:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 27 Jul 2009 11:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7125) JMS Destinations:
 properties "Count" and "Time Last Update" are 0 after sending a message
Message-ID: <1354613486.1248710069330.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7125:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> JMS Destinations: properties "Count" and "Time Last Update" are 0 after sending a message
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-7125
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7125
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging), ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Tests:
> testQueueMetrics*
> testTopicMetrics*
>            Reporter: Ondrej ?i?ka
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> After sending a message(s), the some properties have bad values:
> Count = 0,
> Count Delta = 0,
> Time Last Update = 0,
> However, 
> Depth	4	The current message count of pending messages within the queue waiting for dispatch
> Depth Delta	3	The message count delta of pending messages since last method call
> Did the meaning of  Count change?
> I've looked at the queue MBean in JMX console, and there's no count property. Jopr takes this from ProfilseService, so perhaps that's where zero comes from? Anyway, this is a regression.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 27 14:01:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-119) Hibernate Validator
	4.0.0.Beta2
In-Reply-To: <1098713284.1247792429189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1742292896.1248717689419.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-119:
----------------------------------

    Summary: Hibernate Validator 4.0.0.Beta2  (was: Hibernate Validator 4.0.0Beta2)


> Hibernate Validator 4.0.0.Beta2
> -------------------------------
>
>                 Key: JBJCA-119
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-119
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> for 303 requirement 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 14:03:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-120) Validation API
	1.0.CR3
In-Reply-To: <105271748.1248261929139.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <993979413.1248717809523.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-120:
----------------------------------

    Summary: Validation API 1.0.CR3  (was: javax validation-api 1.0.CR3)


> Validation API 1.0.CR3
> ----------------------
>
>                 Key: JBJCA-120
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-120
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 14:03:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-121) SLF4J 1.5.6
Message-ID: <490362193.1248717809672.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SLF4J 1.5.6
-----------

                 Key: JBJCA-121
                 URL: https://jira.jboss.org/jira/browse/JBJCA-121
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 14:03:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-122) JBoss LogManager
	1.1.0.CR4
Message-ID: <563107268.1248717809750.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss LogManager 1.1.0.CR4
--------------------------

                 Key: JBJCA-122
                 URL: https://jira.jboss.org/jira/browse/JBJCA-122
             Project: JBoss JCA
          Issue Type: Component Upgrade
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 14:07:42 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:07:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-123) Update logging
	framework
Message-ID: <1781074719.1248718062317.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Update logging framework
------------------------

                 Key: JBJCA-123
                 URL: https://jira.jboss.org/jira/browse/JBJCA-123
             Project: JBoss JCA
          Issue Type: Task
          Components: Build, Standalone
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Update the logging framework to use JBoss LogManager 1.1 and dependant libraries.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 14:15:30 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 27 Jul 2009 14:15:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7112) EJB3 Metrics Test
 Failing in trunk
In-Reply-To: <1445531349.1248129869264.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1458178918.1248718530079.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBAS-7112.
---------------------------------------

    Resolution: Done


> EJB3 Metrics Test Failing in trunk
> ----------------------------------
>
>                 Key: JBAS-7112
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7112
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Managed Component not getting deployed?
> junit.framework.AssertionFailedError: Component not found; no managed object with name "testEjb3xMetrics.jar/TestLoggingMDB" in: []
> 	at org.jboss.test.profileservice.test.Ejb3MetricsUnitTestCase.getAndTestManagedComponent(Ejb3MetricsUnitTestCase.java:416)
> 	at org.jboss.test.profileservice.test.Ejb3MetricsUnitTestCase.testMdb(Ejb3MetricsUnitTestCase.java:319)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 14:21:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-124) Remove AOP stack
 from MC configuration
Message-ID: <1533957505.1248718889309.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Remove AOP stack from MC configuration
--------------------------------------

                 Key: JBJCA-124
                 URL: https://jira.jboss.org/jira/browse/JBJCA-124
             Project: JBoss JCA
          Issue Type: Task
          Components: Build, Standalone
    Affects Versions: 1.0.0.Alpha2
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen


Remove the AOP stack from the JBoss Microcontainer configuration, since no deployments actually needs it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 14:25:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-124) Remove AOP stack
 from MC configuration
In-Reply-To: <1533957505.1248718889309.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <472747515.1248719129335.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-124.
-----------------------------------

    Resolution: Done


> Remove AOP stack from MC configuration
> --------------------------------------
>
>                 Key: JBJCA-124
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-124
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Build, Standalone
>    Affects Versions: 1.0.0.Alpha2
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>
> Remove the AOP stack from the JBoss Microcontainer configuration, since no deployments actually needs it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 14:41:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-125) JBoss Classloading
	2.0.6.GA
Message-ID: <827060506.1248720089293.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss Classloading 2.0.6.GA
---------------------------

                 Key: JBJCA-125
                 URL: https://jira.jboss.org/jira/browse/JBJCA-125
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 14:41:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-126) JBoss Deployer
	2.0.8.GA
Message-ID: <290360875.1248720089360.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss Deployer 2.0.8.GA
-----------------------

                 Key: JBJCA-126
                 URL: https://jira.jboss.org/jira/browse/JBJCA-126
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 14:41:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-127) JBoss MC Dependency
	2.0.8.GA
Message-ID: <1297570986.1248720089465.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss MC Dependency 2.0.8.GA
----------------------------

                 Key: JBJCA-127
                 URL: https://jira.jboss.org/jira/browse/JBJCA-127
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 14:43:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-128) JBoss MC Kernel
	2.0.8.GA
Message-ID: <1869359378.1248720209164.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss MC Kernel 2.0.8.GA
------------------------

                 Key: JBJCA-128
                 URL: https://jira.jboss.org/jira/browse/JBJCA-128
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 14:43:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-129) JBoss VFS 2.1.2.GA
Message-ID: <1486842312.1248720209260.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss VFS 2.1.2.GA
------------------

                 Key: JBJCA-129
                 URL: https://jira.jboss.org/jira/browse/JBJCA-129
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 16:21:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jul 2009 16:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-22) Log file is
 randomly truncated when configured from JBossMC/JBossAS
Message-ID: <30688019.1248726089233.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Log file is randomly truncated when configured from JBossMC/JBossAS
-------------------------------------------------------------------

                 Key: JBLOGGING-22
                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-22
             Project: JBoss Logging
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: jboss-logmanager
    Affects Versions: 1.1.0.CR4-jboss-logmanager
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 1.1.0.CR5-jboss-logmanager


Due to strangeness in the way that JBossMC's BeanMetaDataBuilder.addProperty() method works, the file name of the rotating file handlers is sometimes (but not always) set before the append flag, causing the file to be truncated even if append was set to true.

Add constructors such that both properties can be set simultaneously to work around this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 16:23:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jul 2009 16:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBLOGGING-13) Only copy log
 level config over when receiving a JMX notification of type
 "jboss.logging.log4j.reconfigure"
In-Reply-To: <29600234.1236708322487.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <937727644.1248726209217.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated JBLOGGING-13:
---------------------------------

    Assignee:     (was: David Lloyd)


> Only copy log level config over when receiving a JMX notification of type "jboss.logging.log4j.reconfigure"
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-13
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-13
>             Project: JBoss Logging
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logbridge
>    Affects Versions: 1.0.0.CR2-jboss-logbridge
>            Reporter: David Lloyd
>             Fix For: 1.0.1.GA-jboss-logbridge
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 16:55:30 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jul 2009 16:55:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBLOGGING-20) JDK loggign
 isLoggable(Level.FINEST) returns false with Log4J backend
In-Reply-To: <12251162.1245835856606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <832782688.1248728130869.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBLOGGING-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477811#action_12477811 ] 

David Lloyd commented on JBLOGGING-20:
--------------------------------------

Any chance you can hunt down where this problem occurs, and possibly come up with a patch?  The code lives here: http://anonsvn.jboss.org/repos/common/jboss-logbridge/trunk/

> JDK loggign isLoggable(Level.FINEST) returns false with Log4J backend
> ---------------------------------------------------------------------
>
>                 Key: JBLOGGING-20
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-20
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logbridge
>         Environment: JBoss 5.1.0, JDK 1.6u13
>            Reporter: Ondrej Medek
>            Assignee: Dimitris Andreadis
>
> I have code using JDK logging like:
> if (LOG.isLoggable(Level.FINEST)) {
>   LOG.finest("added into list: " + something);
> }
> I have no log. When I use just
> LOG.finest("added into list: " + something);
> I got a log in the log file.
> I use JBoss with Log4J. It is configured to log ALL stuff.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 16:55:31 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jul 2009 16:55:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBLOGGING-20) JDK loggign
 isLoggable(Level.FINEST) returns false with Log4J backend
In-Reply-To: <12251162.1245835856606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <89972444.1248728131004.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned JBLOGGING-20:
------------------------------------

    Assignee: David Lloyd  (was: Dimitris Andreadis)


> JDK loggign isLoggable(Level.FINEST) returns false with Log4J backend
> ---------------------------------------------------------------------
>
>                 Key: JBLOGGING-20
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-20
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logbridge
>         Environment: JBoss 5.1.0, JDK 1.6u13
>            Reporter: Ondrej Medek
>            Assignee: David Lloyd
>
> I have code using JDK logging like:
> if (LOG.isLoggable(Level.FINEST)) {
>   LOG.finest("added into list: " + something);
> }
> I have no log. When I use just
> LOG.finest("added into list: " + something);
> I got a log in the log file.
> I use JBoss with Log4J. It is configured to log ALL stuff.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 16:57:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jul 2009 16:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBLOGGING-6) DatasourceAppender
In-Reply-To: <27181334.1219183415489.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1647530091.1248728249305.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned JBLOGGING-6:
-----------------------------------

    Assignee: David Lloyd  (was: Dimitris Andreadis)


> DatasourceAppender
> ------------------
>
>                 Key: JBLOGGING-6
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-6
>             Project: JBoss Logging
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-log4j
>            Reporter: Luca Stancapiano
>            Assignee: David Lloyd
>             Fix For:  2.0.7.GA-log4j
>
>         Attachments: DatasourceAppender.java
>
>
> hi.... what do you think about a DatasourceAppender? This is very simple. It overrides getConnection and closeConnection methods of org.apache.log4j.jdbc.JDBCAppender class and it is configurable by a *-log4j.xml file. Here there is an example of xml file:
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false">
>   
>    <appender name="DATABASE" class="org.jboss.logging.appender.DatasourceAppender">
>    	  <param name="Threshold" value="INFO"/>
>    	  <param name="datasource" value="java:/PortalDS"/>
>    	  <layout class="org.apache.log4j.PatternLayout">
> 		 <param name="ConversionPattern" value=
> 		"INSERT INTO JBP_LOGGING_SAMPLES_USERS (log_date, log_type, log_user, operation) VALUES ( '%d{yyyy-MM-dd HH:mm:ss.SSS}','%p', '%C;%L', '%C;%L')"/>
>       </layout>
>    </appender>
>    
>    <category name="org.jboss.portal.core.identity.UsersActivityStatsServiceImpl">
>       <appender-ref ref="DATABASE"/>
>    </category>
>    
> </log4j:configuration>
> it is the same configuration for JDBCAppender but there is a 'datasource' parameter so you can specify the datasource location. Below there is the whole class:
> /*
>  * JBoss, Home of Professional Open Source
>  * Copyright 2005, JBoss Inc., and individual contributors as indicated
>  * by the @authors tag. See the copyright.txt in the distribution for a
>  * full listing of individual contributors.
>  *
>  * This is free software; you can redistribute it and/or modify it
>  * under the terms of the GNU Lesser General Public License as
>  * published by the Free Software Foundation; either version 2.1 of
>  * the License, or (at your option) any later version.
>  *
>  * This software is distributed in the hope that it will be useful,
>  * but WITHOUT ANY WARRANTY; without even the implied warranty of
>  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>  * Lesser General Public License for more details.
>  *
>  * You should have received a copy of the GNU Lesser General Public
>  * License along with this software; if not, write to the Free
>  * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
>  * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
>  */
> package org.jboss.logging.appender;
> import java.sql.Connection;
> import java.sql.SQLException;
> import javax.naming.InitialContext;
> import javax.naming.NamingException;
> import javax.sql.DataSource;
> /**
>  * An extension of the default Log4j JDBCAppender which will use a datasource to
>  * handle datas into database.
>  * 
>  * @version <tt>$Revision: 1958 $</tt>
>  * @author <a href="mailto:jedim at vige.it">Luca Stancapiano</a>
>  */
> public class DatasourceAppender extends org.apache.log4j.jdbc.JDBCAppender {
> 	/**
> 	 * URL of the DB for default connection handling
> 	 */
> 	protected String datasource = "java:/DefaultDS";
> 	protected DataSource ds;
> 	public void setDatasource(final String datasource) {
> 		this.datasource = datasource;
> 	}
> 	/**
> 	 * I override this method to get a connection from datasource.
> 	 */
> 	protected Connection getConnection() throws SQLException {
> 		if (connection == null || connection.isClosed()) {
> 			if (ds == null)
> 				try {
> 					InitialContext ic = new InitialContext();
> 					ds = (DataSource) ic.lookup(datasource);
> 				} catch (NamingException e) {
> 					e.printStackTrace();
> 				}
> 			connection = ds.getConnection();
> 		}
> 		return connection;
> 	}
> 	protected void closeConnection(Connection con) {
> 		try {
> 			connection.close();
> 		} catch (SQLException ex) {
> 			ex.printStackTrace();
> 		}
> 	}
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 16:58:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jul 2009 16:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBLOGGING-6)
	DatasourceAppender
In-Reply-To: <27181334.1219183415489.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1031418111.1248728309795.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBLOGGING-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477813#action_12477813 ] 

David Lloyd commented on JBLOGGING-6:
-------------------------------------

Any chance you can port this to use JBoss LogManager (see http://anonsvn.jboss.org/repos/common/jboss-logmanager/trunk for the source code)?  If you do so, and you include the test cases, I can merge it into this project.

> DatasourceAppender
> ------------------
>
>                 Key: JBLOGGING-6
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-6
>             Project: JBoss Logging
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-log4j
>            Reporter: Luca Stancapiano
>            Assignee: David Lloyd
>             Fix For:  2.0.7.GA-log4j
>
>         Attachments: DatasourceAppender.java
>
>
> hi.... what do you think about a DatasourceAppender? This is very simple. It overrides getConnection and closeConnection methods of org.apache.log4j.jdbc.JDBCAppender class and it is configurable by a *-log4j.xml file. Here there is an example of xml file:
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false">
>   
>    <appender name="DATABASE" class="org.jboss.logging.appender.DatasourceAppender">
>    	  <param name="Threshold" value="INFO"/>
>    	  <param name="datasource" value="java:/PortalDS"/>
>    	  <layout class="org.apache.log4j.PatternLayout">
> 		 <param name="ConversionPattern" value=
> 		"INSERT INTO JBP_LOGGING_SAMPLES_USERS (log_date, log_type, log_user, operation) VALUES ( '%d{yyyy-MM-dd HH:mm:ss.SSS}','%p', '%C;%L', '%C;%L')"/>
>       </layout>
>    </appender>
>    
>    <category name="org.jboss.portal.core.identity.UsersActivityStatsServiceImpl">
>       <appender-ref ref="DATABASE"/>
>    </category>
>    
> </log4j:configuration>
> it is the same configuration for JDBCAppender but there is a 'datasource' parameter so you can specify the datasource location. Below there is the whole class:
> /*
>  * JBoss, Home of Professional Open Source
>  * Copyright 2005, JBoss Inc., and individual contributors as indicated
>  * by the @authors tag. See the copyright.txt in the distribution for a
>  * full listing of individual contributors.
>  *
>  * This is free software; you can redistribute it and/or modify it
>  * under the terms of the GNU Lesser General Public License as
>  * published by the Free Software Foundation; either version 2.1 of
>  * the License, or (at your option) any later version.
>  *
>  * This software is distributed in the hope that it will be useful,
>  * but WITHOUT ANY WARRANTY; without even the implied warranty of
>  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>  * Lesser General Public License for more details.
>  *
>  * You should have received a copy of the GNU Lesser General Public
>  * License along with this software; if not, write to the Free
>  * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
>  * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
>  */
> package org.jboss.logging.appender;
> import java.sql.Connection;
> import java.sql.SQLException;
> import javax.naming.InitialContext;
> import javax.naming.NamingException;
> import javax.sql.DataSource;
> /**
>  * An extension of the default Log4j JDBCAppender which will use a datasource to
>  * handle datas into database.
>  * 
>  * @version <tt>$Revision: 1958 $</tt>
>  * @author <a href="mailto:jedim at vige.it">Luca Stancapiano</a>
>  */
> public class DatasourceAppender extends org.apache.log4j.jdbc.JDBCAppender {
> 	/**
> 	 * URL of the DB for default connection handling
> 	 */
> 	protected String datasource = "java:/DefaultDS";
> 	protected DataSource ds;
> 	public void setDatasource(final String datasource) {
> 		this.datasource = datasource;
> 	}
> 	/**
> 	 * I override this method to get a connection from datasource.
> 	 */
> 	protected Connection getConnection() throws SQLException {
> 		if (connection == null || connection.isClosed()) {
> 			if (ds == null)
> 				try {
> 					InitialContext ic = new InitialContext();
> 					ds = (DataSource) ic.lookup(datasource);
> 				} catch (NamingException e) {
> 					e.printStackTrace();
> 				}
> 			connection = ds.getConnection();
> 		}
> 		return connection;
> 	}
> 	protected void closeConnection(Connection con) {
> 		try {
> 			connection.close();
> 		} catch (SQLException ex) {
> 			ex.printStackTrace();
> 		}
> 	}
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 18:51:29 2009
From: jira-events at lists.jboss.org (Alex Skor (JIRA))
Date: Mon, 27 Jul 2009 18:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7071) use-try-lock
 option in data source configuration files is ignored
In-Reply-To: <329869123.1246546191859.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1351349700.1248735089333.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477827#action_12477827 ] 

Alex Skor commented on JBAS-7071:
---------------------------------

guys, could you attach a JAR file with this change? I don't feel safe building JBoss from source code myself. so, until this problem is fixed in the new build it would be great if you could provide a JAR file people could use with Jboss 5.1.0GA.

> use-try-lock option in data source configuration files is ignored
> -----------------------------------------------------------------
>
>                 Key: JBAS-7071
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7071
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows XP Professional V2002, service pack 3
>            Reporter: Mike Conner
>            Assignee: Jesper Pedersen
>            Priority: Minor
>
> (FYI  your "READ THIS BEFORE ENTERING NEW REPORTS" points to a  "You caught us doing a little maintenance..." page, so pardon me if I missed something in procedure. )
> The data source configuration property "use-try-lock" is effectively ignored.
> This is because the value is defined in configuration as a long, but the object that is actually set on  an
> org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory  extends 
>    org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnectionFactory
> This class defines it as taking an int, not a long:
>    public void setUseTryLock(int useTryLock)
> As such, reflection in ManagedConnectionFactoryDeployment.setManagedConnectionFactoryAttribute() does not find the method and simply logs it at a trace level, so the value never gets set.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 21:32:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 27 Jul 2009 21:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1869) Upgrade
 jboss-ejb3-build dependency in testsuite to 1.0.5-SNAPSHOT
In-Reply-To: <1684396779.1247485589262.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1464931947.1248744749229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1869.
------------------------------------

    Resolution: Done


> Upgrade jboss-ejb3-build dependency in testsuite to 1.0.5-SNAPSHOT
> ------------------------------------------------------------------
>
>                 Key: EJBTHREE-1869
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1869
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: testsuite
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> The jobs on slaves of mike are failing to resolve the 1.0.4-SNAPSHOT or 1.0.4 of jboss-ejb3-build for 2 reasons:
> 1) The 1.0.4-SNAPSHOT of jboss-ejb3-build is not available through the relative path
> 2) The Maven settings on slaves are not pointing to jboss repo.
> As a workaround, upgrade the jboss-ejb3-build dependency in testsuite to 1.0.5-SNAPSHOT (so that it is resolved locally through relative path).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 22:35:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Mon, 27 Jul 2009 22:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-1077) Fix problem in
 CompressingMarshaller
In-Reply-To: <21329107.1230710934327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <35203460.1248748529373.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBREM-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477836#action_12477836 ] 

Ron Sigal commented on JBREM-1077:
----------------------------------

Applied Doychin Bondzhev's fix to branches 2.2 and 2.x.  Also, added buffered streams to branch 2.2.

Testing:

  * Unit test: org.jboss.test.remoting.marshall.compress.NewCompressingMarshallerTestCase

  * Also, tested with an EJB3 in EAP 4.3.0.GA_CP04

Waiting for results in hudson.

> Fix problem in CompressingMarshaller
> ------------------------------------
>
>                 Key: JBREM-1077
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1077
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11
>            Reporter: Ron Sigal
>            Assignee: Ron Sigal
>             Fix For: 2.5.2 (Flounder), 2.2.3.SP1
>
>         Attachments: CompressionInvokerMarshaller.java, CompressionInvokerUnmarshaller.java
>
>
> In org.jboss.remoting.marshal.compress.CompressingMarshaller.write(),
>       gzos.finish();
>       oos.flush();
> should be
>       oos.flush();
>       bos.flush();
>       gzos.flush();
>       gzos.finish();
> as it is on the 2.x branch.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 22:39:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Mon, 27 Jul 2009 22:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-1077) Fix problem in
 CompressingMarshaller
In-Reply-To: <21329107.1230710934327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <301684494.1248748769272.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBREM-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ron Sigal updated JBREM-1077:
-----------------------------

    Attachment: jboss-remoting.jar


Attaching jboss-remoting.jar from 2.2 branch.  It will print 

   Remoting version: 2.2.3.SP1-preview: 7/27/09-22:21

when it is loaded.

> Fix problem in CompressingMarshaller
> ------------------------------------
>
>                 Key: JBREM-1077
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1077
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11
>            Reporter: Ron Sigal
>            Assignee: Ron Sigal
>             Fix For: 2.5.2 (Flounder), 2.2.3.SP1
>
>         Attachments: CompressionInvokerMarshaller.java, CompressionInvokerUnmarshaller.java, jboss-remoting.jar
>
>
> In org.jboss.remoting.marshal.compress.CompressingMarshaller.write(),
>       gzos.finish();
>       oos.flush();
> should be
>       oos.flush();
>       bos.flush();
>       gzos.flush();
>       gzos.finish();
> as it is on the 2.x branch.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 22:41:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Mon, 27 Jul 2009 22:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-1077) Fix problem in
 CompressingMarshaller
In-Reply-To: <21329107.1230710934327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1170542219.1248748889666.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBREM-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ron Sigal updated JBREM-1077:
-----------------------------

    Attachment: jboss-remoting.jar


Attached jboss-remoting.jar from branch 2.x.  It will print

  Remoting version: 2.5.2 (Flounder) preview: 7/27/09-20:53

when it is loaded.

> Fix problem in CompressingMarshaller
> ------------------------------------
>
>                 Key: JBREM-1077
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1077
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11
>            Reporter: Ron Sigal
>            Assignee: Ron Sigal
>             Fix For: 2.5.2 (Flounder), 2.2.3.SP1
>
>         Attachments: CompressionInvokerMarshaller.java, CompressionInvokerUnmarshaller.java, jboss-remoting.jar, jboss-remoting.jar
>
>
> In org.jboss.remoting.marshal.compress.CompressingMarshaller.write(),
>       gzos.finish();
>       oos.flush();
> should be
>       oos.flush();
>       bos.flush();
>       gzos.flush();
>       gzos.finish();
> as it is on the 2.x branch.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 27 22:47:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Mon, 27 Jul 2009 22:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-1077) Fix problem in
 CompressingMarshaller
In-Reply-To: <21329107.1230710934327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <559538465.1248749249942.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBREM-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ron Sigal updated JBREM-1077:
-----------------------------

    Attachment: ejb3-compression.tgz


Attaching tgz file with EJB3 example.  

"ant" will deploy the example the example to JBossAS (according to the value of jboss.home in the local.properties file). 

"ant run" will run the example

> Fix problem in CompressingMarshaller
> ------------------------------------
>
>                 Key: JBREM-1077
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1077
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11
>            Reporter: Ron Sigal
>            Assignee: Ron Sigal
>             Fix For: 2.5.2 (Flounder), 2.2.3.SP1
>
>         Attachments: CompressionInvokerMarshaller.java, CompressionInvokerUnmarshaller.java, ejb3-compression.tgz, jboss-remoting.jar, jboss-remoting.jar
>
>
> In org.jboss.remoting.marshal.compress.CompressingMarshaller.write(),
>       gzos.finish();
>       oos.flush();
> should be
>       oos.flush();
>       bos.flush();
>       gzos.flush();
>       gzos.finish();
> as it is on the 2.x branch.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 00:14:29 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Tue, 28 Jul 2009 00:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
Message-ID: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Unable to consume more than  777,000 messages
---------------------------------------------

                 Key: JBMESSAGING-1693
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0
         Environment: Windows Vista, 32 bit, 2GB RAM
            Reporter: Bijith Kumar
            Assignee: Tim Fox
            Priority: Critical


Using messaging-2.0.0.BETA3 stand alone non-clustered
-------------------------------------------------------------------------------
I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
 <global-page-size>10485760</global-page-size>
<paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 

Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
-Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

Please find the attached java files. Test instructions are given below
1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
4) Observe from JConsole that after the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
5) Observe that after a while consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by substracting MessageCount  from messagedAdded. Following are the values I got for last three runs
Messages Consumed = messagedAdded -  MessageCount  
 a) 800246 - 23246 = 777000
 b) 799037 - 22037 = 777000
 c)  799037 - 22037 = 777000

It seems the number of messages consumed (777000 in above case) is driven by message size.  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 00:16:49 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Tue, 28 Jul 2009 00:16:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
In-Reply-To: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1144808404.1248754609456.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1693:
--------------------------------------

    Attachment: src.rar


Attaching files

> Unable to consume more than  777,000 messages
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1693
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>         Environment: Windows Vista, 32 bit, 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>            Priority: Critical
>         Attachments: src.rar
>
>
> Using messaging-2.0.0.BETA3 stand alone non-clustered
> -------------------------------------------------------------------------------
> I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
>  <global-page-size>10485760</global-page-size>
> <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 
> Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
> -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
> Please find the attached java files. Test instructions are given below
> 1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
> 2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
> 3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
> 4) Observe from JConsole that after the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
> 5) Observe that after a while consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by substracting MessageCount  from messagedAdded. Following are the values I got for last three runs
> Messages Consumed = messagedAdded -  MessageCount  
>  a) 800246 - 23246 = 777000
>  b) 799037 - 22037 = 777000
>  c)  799037 - 22037 = 777000
> It seems the number of messages consumed (777000 in above case) is driven by message size.  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 00:32:29 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Tue, 28 Jul 2009 00:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
In-Reply-To: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1218801317.1248755549383.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1693:
--------------------------------------

    Description: 
Using messaging-2.0.0.BETA3 stand alone non-clustered
-------------------------------------------------------------------------------
I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
 <global-page-size>10485760</global-page-size>
<paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 

Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
-Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

Please find the attached java files. Test instructions are given below
1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by substracting MessageCount  from messagedAdded. Following are the values I got for last three runs
Messages Consumed = messagedAdded -  MessageCount  
 a) 800246 - 23246 = 777000
 b) 799037 - 22037 = 777000
 c)  799037 - 22037 = 777000

It seems the number of messages consumed (777000 in above case) is driven by message size.  Because, when I tried another message, the consumption hanged after 780,000 messages.

  was:
Using messaging-2.0.0.BETA3 stand alone non-clustered
-------------------------------------------------------------------------------
I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
 <global-page-size>10485760</global-page-size>
<paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 

Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
-Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

Please find the attached java files. Test instructions are given below
1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
4) Observe from JConsole that after the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
5) Observe that after a while consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by substracting MessageCount  from messagedAdded. Following are the values I got for last three runs
Messages Consumed = messagedAdded -  MessageCount  
 a) 800246 - 23246 = 777000
 b) 799037 - 22037 = 777000
 c)  799037 - 22037 = 777000

It seems the number of messages consumed (777000 in above case) is driven by message size.  Because, when I tried another message, the consumption hanged after 780,000 messages.



> Unable to consume more than  777,000 messages
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1693
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>         Environment: Windows Vista, 32 bit, 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>            Priority: Critical
>         Attachments: src.rar
>
>
> Using messaging-2.0.0.BETA3 stand alone non-clustered
> -------------------------------------------------------------------------------
> I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
>  <global-page-size>10485760</global-page-size>
> <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 
> Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
> -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
> Please find the attached java files. Test instructions are given below
> 1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
> 2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
> 3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
> 4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
> 5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by substracting MessageCount  from messagedAdded. Following are the values I got for last three runs
> Messages Consumed = messagedAdded -  MessageCount  
>  a) 800246 - 23246 = 777000
>  b) 799037 - 22037 = 777000
>  c)  799037 - 22037 = 777000
> It seems the number of messages consumed (777000 in above case) is driven by message size.  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 00:32:29 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Tue, 28 Jul 2009 00:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
In-Reply-To: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <756939980.1248755549515.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1693:
--------------------------------------

    Description: 
Using messaging-2.0.0.BETA3 stand alone non-clustered
-------------------------------------------------------------------------------
I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
 <global-page-size>10485760</global-page-size>
<paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 

Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
-Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

Please find the attached java files. Test instructions are given below
1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
Messages Consumed = messagesAdded -  MessageCount  
 a) 800246 - 23246 = 777000
 b) 799037 - 22037 = 777000
 c)  799037 - 22037 = 777000

It seems the number of messages consumed (777000 in above case) is driven by message size.  Because, when I tried another message, the consumption hanged after 780,000 messages.

  was:
Using messaging-2.0.0.BETA3 stand alone non-clustered
-------------------------------------------------------------------------------
I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
 <global-page-size>10485760</global-page-size>
<paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 

Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
-Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

Please find the attached java files. Test instructions are given below
1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by substracting MessageCount  from messagedAdded. Following are the values I got for last three runs
Messages Consumed = messagedAdded -  MessageCount  
 a) 800246 - 23246 = 777000
 b) 799037 - 22037 = 777000
 c)  799037 - 22037 = 777000

It seems the number of messages consumed (777000 in above case) is driven by message size.  Because, when I tried another message, the consumption hanged after 780,000 messages.



> Unable to consume more than  777,000 messages
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1693
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>         Environment: Windows Vista, 32 bit, 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>            Priority: Critical
>         Attachments: src.rar
>
>
> Using messaging-2.0.0.BETA3 stand alone non-clustered
> -------------------------------------------------------------------------------
> I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
>  <global-page-size>10485760</global-page-size>
> <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 
> Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
> -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
> Please find the attached java files. Test instructions are given below
> 1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
> 2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
> 3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
> 4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
> 5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
> Messages Consumed = messagesAdded -  MessageCount  
>  a) 800246 - 23246 = 777000
>  b) 799037 - 22037 = 777000
>  c)  799037 - 22037 = 777000
> It seems the number of messages consumed (777000 in above case) is driven by message size.  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 02:08:29 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Tue, 28 Jul 2009 02:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
In-Reply-To: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2027383767.1248761309246.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1693:
--------------------------------------

    Description: 
Using messaging-2.0.0.BETA3 stand alone non-clustered
-------------------------------------------------------------------------------
I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
 <global-page-size>10485760</global-page-size>
<paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 

Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
-Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

Please find the attached java files. Test instructions are given below
1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
Messages Consumed = messagesAdded -  MessageCount  
 a) 800246 - 23246 = 777000
 b) 799037 - 22037 = 777000
 c)  799037 - 22037 = 777000

It seems the number of messages consumed (777000 in above case) is driven by message size (and Queue size).  Because, when I tried another message, the consumption hanged after 780,000 messages.

  was:
Using messaging-2.0.0.BETA3 stand alone non-clustered
-------------------------------------------------------------------------------
I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
 <global-page-size>10485760</global-page-size>
<paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 

Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
-Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

Please find the attached java files. Test instructions are given below
1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
Messages Consumed = messagesAdded -  MessageCount  
 a) 800246 - 23246 = 777000
 b) 799037 - 22037 = 777000
 c)  799037 - 22037 = 777000

It seems the number of messages consumed (777000 in above case) is driven by message size.  Because, when I tried another message, the consumption hanged after 780,000 messages.



> Unable to consume more than  777,000 messages
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1693
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>         Environment: Windows Vista, 32 bit, 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>            Priority: Critical
>         Attachments: src.rar
>
>
> Using messaging-2.0.0.BETA3 stand alone non-clustered
> -------------------------------------------------------------------------------
> I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
>  <global-page-size>10485760</global-page-size>
> <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 
> Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
> -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
> Please find the attached java files. Test instructions are given below
> 1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
> 2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
> 3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
> 4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
> 5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
> Messages Consumed = messagesAdded -  MessageCount  
>  a) 800246 - 23246 = 777000
>  b) 799037 - 22037 = 777000
>  c)  799037 - 22037 = 777000
> It seems the number of messages consumed (777000 in above case) is driven by message size (and Queue size).  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 03:27:30 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 28 Jul 2009 03:27:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7126) Include farm folder
 in the VFSCache permanent roots configuration
Message-ID: <535403161.1248766050126.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Include farm folder in the VFSCache permanent roots configuration
-----------------------------------------------------------------

                 Key: JBAS-7126
                 URL: https://jira.jboss.org/jira/browse/JBAS-7126
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: VFS
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: jaikiran pai
            Assignee: jaikiran pai


The "farm" folder is missing from the VFSCache configuration for permanent roots. This results in the well-known disk space usage issue with tmp files in AS-5.x.

Adding the "farm" folder URL should fix the issue.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 03:52:42 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Tue, 28 Jul 2009 03:52:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBLOGGING-20) JDK loggign
 isLoggable(Level.FINEST) returns false with Log4J backend
In-Reply-To: <12251162.1245835856606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <699248592.1248767562759.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBLOGGING-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477856#action_12477856 ] 

Ondrej Medek commented on JBLOGGING-20:
---------------------------------------

Well, I do not know exactly, where is the problem, but I think I have found two bugs.

The LOG is org.jboss.logmanager.LoggerInstance and this class is subclass of java.util.logging.Logger. The LoggerInstance class overrides the isLoggable(Level) method from the Logger class. This overridden method LoggerInstance.isLoggable(Level) uses a new value called effectiveLevel, which is:

effectiveLevel = 800, i.e. default value I guess, when I have configured to log ALL stuff for my category in log4j config file. It should be INT.MIN_VALUE (= Level.ALL.intValue()) instead.
effectiveLevel = 400, when I have configured to log TRACE stuff for my category in log4j config file. I.e. is is the same value, as Level.FINE.

Bug 1) Setting ALL level for the category in config file should set the effectiveLevel to Level.ALL.intValue().

Bug 2) Setting TRACE level for the category in config file makes the LOG.isLoggable(FINEST) always false, but LOG.finest("...") does make a log.

IMHO this "LoggerInstance.effectiveLevel" stuff is half baken: it is used only in isLoggable(), but is not used in the log() methods (doLog, fine, finer, finest, ...). Maybe it should be removed and the original Logger.levelValue should be used instead?  Then LoggerInstance would not need to override isLoggable().

> JDK loggign isLoggable(Level.FINEST) returns false with Log4J backend
> ---------------------------------------------------------------------
>
>                 Key: JBLOGGING-20
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-20
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logbridge
>         Environment: JBoss 5.1.0, JDK 1.6u13
>            Reporter: Ondrej Medek
>            Assignee: David Lloyd
>
> I have code using JDK logging like:
> if (LOG.isLoggable(Level.FINEST)) {
>   LOG.finest("added into list: " + something);
> }
> I have no log. When I use just
> LOG.finest("added into list: " + something);
> I got a log in the log file.
> I use JBoss with Log4J. It is configured to log ALL stuff.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 04:00:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 28 Jul 2009 04:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7126) Include farm folder
 in the VFSCache permanent roots configuration
In-Reply-To: <535403161.1248766050126.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <634410491.1248768029238.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBAS-7126.
--------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1
       Resolution: Done


Added 

<entry>
		<key>${jboss.server.home.url}farm</key>
		<value><inject bean="VfsNamesExceptionHandler"/></value>
	</entry>

to [Branch_5_x/trunk]/server/src/etc/conf/all/bootstrap/vfs.xml. This file gets reused during AS build in the "default" server configuration too. With the inclusion of "farm" folder in the VFSCache configuration, both the "all" and "default" server configuration boot up fine (even if farm folder is non-existent in default server configuration). 

Marking as resolved.


> Include farm folder in the VFSCache permanent roots configuration
> -----------------------------------------------------------------
>
>                 Key: JBAS-7126
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7126
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: VFS
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The "farm" folder is missing from the VFSCache configuration for permanent roots. This results in the well-known disk space usage issue with tmp files in AS-5.x.
> Adding the "farm" folder URL should fix the issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 04:53:29 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Tue, 28 Jul 2009 04:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1687) Transaction
 management/demarcation and ack modes/session creation broken in JCA RA
In-Reply-To: <615256574.1247823389304.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <733968770.1248771209574.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor closed JBMESSAGING-1687.
------------------------------------

    Fix Version/s: 2.0.0.beta4
                       (was: 2.0.0)
       Resolution: Done


> Transaction management/demarcation and ack modes/session creation broken in JCA RA
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1687
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1687
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Andy Taylor
>            Priority: Critical
>             Fix For: 2.0.0.beta4
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 05:01:29 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Tue, 28 Jul 2009 05:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7046) Support CDI
 injection into Java EE component classes
In-Reply-To: <24256304.1245752876415.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1075443976.1248771689161.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pete Muir updated JBAS-7046:
----------------------------

    Summary: Support CDI injection into Java EE component classes  (was: Support CDI injection into managed Servlet objects)


> Support CDI injection into Java EE component classes
> ----------------------------------------------------
>
>                 Key: JBAS-7046
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7046
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Pete Muir
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 05:07:29 2009
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 28 Jul 2009 05:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7046) Support CDI
 injection into Java EE component classes
In-Reply-To: <24256304.1245752876415.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <751369223.1248772049289.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477863#action_12477863 ] 

Jozef Hartinger commented on JBAS-7046:
---------------------------------------

covered by JSR-299 TCK
org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.InjectionIntoNonContextualComponentTest.testInjectionIntoServlet()
org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.InjectionIntoNonContextualComponentTest.testInjectionIntoFilter()
org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.InjectionIntoNonContextualComponentTest.testInjectionIntoServletListener()
org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.InjectionIntoNonContextualComponentTest.testInjectionIntoTagHandler()
org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.InjectionIntoNonContextualComponentTest.testInjectionIntoTagLibraryListener()
org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.InjectionIntoNonContextualComponentTest.testInjectionIntoJSFManagedBean()
org.jboss.jsr299.tck.tests.lookup.injection.enterprise.SessionBeanInjectionTest.testInjectionOnEJBInterceptor()

> Support CDI injection into Java EE component classes
> ----------------------------------------------------
>
>                 Key: JBAS-7046
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7046
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Pete Muir
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 05:49:29 2009
From: jira-events at lists.jboss.org (Miro Selent (JIRA))
Date: Tue, 28 Jul 2009 05:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1016) memory leak in GMS
	protocol
Message-ID: <1523793676.1248774569291.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

memory leak in GMS protocol
---------------------------

                 Key: JGRP-1016
                 URL: https://jira.jboss.org/jira/browse/JGRP-1016
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.7
            Reporter: Miro Selent
            Assignee: Bela Ban
            Priority: Critical


Found in org.jgroups.protocols.pbcast.GMS in a scenario where members were killed and restarted very frequently and one member is persistently running. The memory consumption icreased very quickly until OutOfMemory.

Our analysis with JProfiler leads to the following assumption:
The number of org.jgroups.stack.IpAddress held by merge_ack_collector icreases every time a member was (re)started. 
These instances were never removed because no MERGE events occured. This is completely clear since there was only one coordinator (the long running member). 
If GMS receives no MERGE event it never cleans up the stored IpAddress instances in the merge_ack_collector.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 06:39:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 28 Jul 2009 06:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1388178155.1248777569224.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477873#action_12477873 ] 

Howard Gao commented on JBMESSAGING-1685:
-----------------------------------------

Hi Martin,

Thanks for the info. I examined my first test and found it's not a valid one. The reason is that for every loop it sends 200 messages and only received one. So the 199 messages are left in the queue. As you added the loops the message are accumulated and eventually use up the memory.

I attached a new test that comsumes all the messages after roll back so no messages are left in each loop. And it passes 1000 loops safely.

To run the test, you need to add "MaxDeliveryAttempts" to 2000 in the queue configuration file so message won't be put to the DLQ after 10 times of roll backs.

Can you take a look (it's QueueExampleLong2.java)? Thanks.

Howard



> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java, QueueExampleLong.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 06:45:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 28 Jul 2009 06:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2035891158.1248777929602.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1685:
------------------------------------

    Attachment: QueueExampleLong2.java


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java, QueueExampleLong.java, QueueExampleLong2.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 08:15:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 28 Jul 2009 08:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1694) -1 is a valid
 value for connection-ttl & client-failure-check -period
Message-ID: <258915794.1248783329841.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

-1 is a valid value for connection-ttl & client-failure-check -period
---------------------------------------------------------------------

                 Key: JBMESSAGING-1694
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1694
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Facade
    Affects Versions: 2.0.0.beta4
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 2.0.0


in JMSServerDeployer, we validate that client-failure-check-period & connection-ttl values are greater or equals to zero.
This is not correct, these values can be equals to -1 (meaning infinite) or greater than 0

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 08:15:30 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 28 Jul 2009 08:15:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1694) -1 is a valid
 value for connection-ttl & client-failure-check -period
In-Reply-To: <258915794.1248783329841.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1470205708.1248783330002.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1694.
------------------------------------

    Resolution: Done


fixed in the trunk

> -1 is a valid value for connection-ttl & client-failure-check -period
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1694
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1694
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 2.0.0.beta4
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> in JMSServerDeployer, we validate that client-failure-check-period & connection-ttl values are greater or equals to zero.
> This is not correct, these values can be equals to -1 (meaning infinite) or greater than 0

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 08:35:29 2009
From: jira-events at lists.jboss.org (Jean-David Maillefer (JIRA))
Date: Tue, 28 Jul 2009 08:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-216) Many of the schema
 and DTD on http://www.jboss.org/j2ee/ are invalid
Message-ID: <1516074926.1248784529231.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Many of the schema and DTD on http://www.jboss.org/j2ee/ are  invalid
---------------------------------------------------------------------

                 Key: JBMETA-216
                 URL: https://jira.jboss.org/jira/browse/JBMETA-216
             Project: JBoss Metadata
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: Irrelevant, except that I use eclipse Galileo to develop (and validate) the JBoss configuration files
            Reporter: Jean-David Maillefer
            Assignee: Alexey Loubyansky
            Priority: Minor


The following files available on the web (http://www.jboss.org/j2ee/) are not valid:

Description	Resource	Path	Location	Type
A '(' character or an element type is required in the declaration of element type "simpleType".	datatypes.dtd	/SITData/j2ee/dtd	line 95	DTD Problem
Type	Path	Resource	Location	Description
DTD Problem	j2ee/dtd	datatypes.dtd	line 95	A '(' character or an element type is required in the declaration of element type "simpleType".
DTD Problem	j2ee/dtd	jaws.dtd	line 13	The element 'cmp-field' has not been declared.
DTD Problem	j2ee/dtd	jboss-ds_5_0.dtd	line 34	The element 'background-validation-millis' has not been declared.
DTD Problem	j2ee/dtd	jboss-ds_5_0.dtd	line 417	The element 'background-validation-millis' has not been declared.
DTD Problem	j2ee/dtd	jboss-ds_5_0.dtd	line 425	The element 'background-validation-millis' has not been declared.
DTD Problem	j2ee/dtd	jboss-ds_5_0.dtd	line 49	The element 'background-validation-millis' has not been declared.
DTD Problem	j2ee/dtd	jboss-ds_5_0.dtd	line 62	The element 'background-validation-millis' has not been declared.
DTD Problem	j2ee/dtd	jboss-web_4_0.dtd	line 367	The element 'false' has not been declared.
DTD Problem	j2ee/dtd	jboss-web_4_0.dtd	line 367	The element 'true' has not been declared.
DTD Problem	j2ee/dtd	jboss-web_4_0.dtd	line 455	The element 'key' has not been declared.
DTD Problem	j2ee/dtd	jboss-web_4_0.dtd	line 455	The element 'value' has not been declared.
DTD Problem	j2ee/dtd	jboss-web_4_2.dtd	line 374	The element 'false' has not been declared.
DTD Problem	j2ee/dtd	jboss-web_4_2.dtd	line 374	The element 'true' has not been declared.
DTD Problem	j2ee/dtd	jboss-web_4_2.dtd	line 462	The element 'key' has not been declared.
DTD Problem	j2ee/dtd	jboss-web_4_2.dtd	line 462	The element 'value' has not been declared.
XML Schema Problem	j2ee/schema	jboss_5_0.xsd	line 410	cos-nonambig: "http://www.jboss.com/xml/ns/javaee":security-identity and "http://www.jboss.com/xml/ns/javaee":security-identity (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
XML Schema Problem	j2ee/schema	jboss_5_1.xsd	line 349	cos-nonambig: "http://www.jboss.com/xml/ns/javaee":security-identity and "http://www.jboss.com/xml/ns/javaee":security-identity (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
XML Schema Problem	j2ee/schema	jbxb_1_0.xsd	line 19	src-resolve.4.2: Error resolving component 'jbxb:package'. It was detected that 'jbxb:package' is in namespace 'http://www.jboss.org/xml/ns/jbxb', but components from this namespace are not referenceable from schema document 'file:///C:/eclipse-workspace/SITData/j2ee/schema/jbxb_1_0.xsd'. If this is the incorrect namespace, perhaps the prefix of 'jbxb:package' needs to be changed. If this is the correct namespace, then an appropriate 'import' tag should be added to 'file:///C:/eclipse-workspace/SITData/j2ee/schema/jbxb_1_0.xsd'.
XML Schema Problem	j2ee/schema	jbxb_1_0.xsd	line 94	src-element.3: Element 'class' has both a 'type' attribute and a 'anonymous type' child. Only one of these is allowed for an element.
XML Schema Problem	j2ee/schema	web-jsptaglibrary_2_0.xsd	line 1	Referenced file contains errors (j2ee/schema/j2ee_1_4.xsd).  Details: sch-props-correct.2: A schema cannot contain two global components with the same name; this schema contains two occurrences of "http://java.sun.com/xml/ns/j2ee,listenerType'. line 722


The following files available from SVN (JBossAS/projects/metadata/trunk/src/main/resources 90580) are not valid:
Type	Path	Resource	Location	Description	Fix
DTD Problem	j2ee/dtd	connector_1_6.dtd	line 78	The element 'required-inflow-context' has not been declared.	add missing declaration
DTD Problem	j2ee/dtd	datatypes.dtd	line 95	A '(' character or an element type is required in the declaration of element type "simpleType".	TODO
DTD Problem	j2ee/dtd	jaws.dtd	line 13	The element 'cmp-field' has not been declared.	add missing declaration
DTD Problem	j2ee/dtd	jboss-web_4_0.dtd	line 367	The element 'true' has not been declared.	add missing declaration
DTD Problem	j2ee/dtd	jboss-web_4_0.dtd	line 367	The element 'false' has not been declared.	add missing declaration
DTD Problem	j2ee/dtd	jboss-web_4_0.dtd	line 455	The element 'key' has not been declared.	add missing declaration
DTD Problem	j2ee/dtd	jboss-web_4_0.dtd	line 455	The element 'value' has not been declared.	add missing declaration
DTD Problem	j2ee/dtd	jboss-web_4_2.dtd	line 374	The element 'false' has not been declared.	add missing declaration
DTD Problem	j2ee/dtd	jboss-web_4_2.dtd	line 374	The element 'true' has not been declared.	add missing declaration
DTD Problem	j2ee/dtd	jboss-web_4_2.dtd	line 462	The element 'key' has not been declared.	add missing declaration
DTD Problem	j2ee/dtd	jboss-web_4_2.dtd	line 462	The element 'value' has not been declared.	add missing declaration
XML Schema Problem	j2ee/schema	jboss_5_1.xsd	line 1218	src-resolve: Cannot resolve the name 'jboss:webservice-descriptionType' to a(n) 'type definition' component.	update http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd to latest version
XML Schema Problem	j2ee/schema	jboss-web_5_1.xsd	line 95	src-resolve: Cannot resolve the name 'jboss:webservice-descriptionType' to a(n) 'type definition' component.	update http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd to latest version
XML Schema Problem	j2ee/schema	jbxb_1_0.xsd	line 19	src-resolve.4.2: Error resolving component 'jbxb:package'. It was detected that 'jbxb:package' is in namespace 'http://www.jboss.org/xml/ns/jbxb', but components from this namespace are not referenceable from schema document 'j2ee/schema/jbxb_1_0.xsd'. If this is the incorrect namespace, perhaps the prefix of 'jbxb:package' needs to be changed. If this is the correct namespace, then an appropriate 'import' tag should be added to 'j2ee/schema/jbxb_1_0.xsd'.	TODO
XML Schema Problem	j2ee/schema	jbxb_1_0.xsd	line 94	src-element.3: Element 'class' has both a 'type' attribute and a 'anonymous type' child. Only one of these is allowed for an element.	TODO
XML Schema Problem	j2ee/schema	web-jsptaglibrary_2_0.xsd	line 1	Referenced file contains errors (j2ee/schema/j2ee_1_4.xsd).  Details: sch-props-correct.2: A schema cannot contain two global components with the same name; this schema contains two occurrences of "http://java.sun.com/xml/ns/j2ee,listenerType'. line 722	TODO


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 09:29:29 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Tue, 28 Jul 2009 09:29:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1482870715.1248787769356.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------


hi howard, thanks for your feedback. now that all messages are received (and commited) the OOM condition no longer occurs. i'm sorry i did not figure out the issue in the test routine as well.
nevertheless the issue is still existent as the application guy does not issue a commit() until the message has been successfully processed (archived the document and updated some index tables). the application works in the same fashion as the main() method, it sleeps for a while, retries, rolls back, sleeps again. if the scanning process is heavily used hundreds of open messages queue up and are rolled back again and again. if the outage of the archive system or database server takes some time, the OOM occurs sooner or later.
what is expected is that if MaxDeliveryAttempts is reached, the message is discarded (or put to a DLQ, if defined) and the associated memory should be cleaned up. there should be no need to issue a commit(), the memory in my opinion should be freed at the latest when the connection is closed. as it is also done in our example (before going to sleep again).
thanks very much for your efforts putting into this.
kind regards martin

> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java, QueueExampleLong.java, QueueExampleLong2.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 09:29:29 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Tue, 28 Jul 2009 09:29:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7125) JMS Destinations:
 properties "Count" and "Time Last Update" are 0 after sending a message
Message-ID: <1027791533.1248787769488.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej ?i?ka updated JBAS-7125:
-------------------------------

    Description: 
After sending a message(s), some properties have bad values:

Count = 0,
Count Delta = 0,
Time Last Update = 0,

However, 

Depth	4	The current message count of pending messages within the queue waiting for dispatch
Depth Delta	3	The message count delta of pending messages since last method call

Did the meaning of  Count change?

I've looked at the queue MBean in JMX console, and there's no count property. Jopr takes this from ProfilseService, so perhaps that's where zero comes from? Anyway, this is a regression.

  was:
After sending a message(s), the some properties have bad values:

Count = 0,
Count Delta = 0,
Time Last Update = 0,

However, 

Depth	4	The current message count of pending messages within the queue waiting for dispatch
Depth Delta	3	The message count delta of pending messages since last method call

Did the meaning of  Count change?

I've looked at the queue MBean in JMX console, and there's no count property. Jopr takes this from ProfilseService, so perhaps that's where zero comes from? Anyway, this is a regression.



> JMS Destinations: properties "Count" and "Time Last Update" are 0 after sending a message
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-7125
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7125
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging), ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Tests:
> testQueueMetrics*
> testTopicMetrics*
>            Reporter: Ondrej ?i?ka
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> After sending a message(s), some properties have bad values:
> Count = 0,
> Count Delta = 0,
> Time Last Update = 0,
> However, 
> Depth	4	The current message count of pending messages within the queue waiting for dispatch
> Depth Delta	3	The message count delta of pending messages since last method call
> Did the meaning of  Count change?
> I've looked at the queue MBean in JMX console, and there's no count property. Jopr takes this from ProfilseService, so perhaps that's where zero comes from? Anyway, this is a regression.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Tue Jul 28 10:36:30 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 28 Jul 2009 10:36:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1550) Core
 BridgeConfiguration with a discovery group is not deployed
In-Reply-To: <22813655.1237480462871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1780929951.1248791790286.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned JBMESSAGING-1550:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> Core BridgeConfiguration with a discovery group is not deployed
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1550
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1550
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> A Core BridgeConfiguration can be set with either a discovery group or a pair of connectors.
> When the bridge is deployed (in ClusterManager.start()), we only check for the pair of connectors.
> If the bridge config uses a discovery group, it will never be deployed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 11:56:42 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Udo_Klinkm=C3=BCller_=28JIRA=29?=)
Date: Tue, 28 Jul 2009 11:56:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2218) Unknown error
 while parsing. This is a bug. Please contact the Development team.
Message-ID: <1817292291.1248796602094.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Unknown error while parsing. This is a bug. Please contact the Development team.
--------------------------------------------------------------------------------

                 Key: JBRULES-2218
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2218
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse
    Affects Versions: 5.0.0.FINAL
         Environment: Eclipse 3.5 (Galileo), Mac OS X
            Reporter: Udo Klinkm?ller
            Assignee: Mark Proctor


rule "Arrival-Delayed-Upd"
	salience 1000 
	when
		#conditions
		VisitPair( $ov: oldVisit != null, $nv: visit )
		$oaf: ArrivalFlight( onBlock == null, $ost: scheduledTime != null, $op: position != null ) from $ov.arrivalFlight
		$naf: ArrivalFlight( onBlock == null, (($nst: scheduledTime != null, != $ost) || ($np: position != null, != $op)) ) from $nv.arrivalFlighT
		
	then 
		#actions
		Date vf = addMinutes($nst, 15); 
		ResourceEvent re = eventBuilderFactory.getResourceVisitEventBuilder(EventType.ARRIVAL_DELAYED, $naf.getPositionKey(), vf)
			.visitKey($nv.getKey())
			.build();
		eventHandler.handleEvent(re);
end

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Tue Jul 28 14:59:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 28 Jul 2009 14:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7127) Upgrade JBoss JAXR
	to 2.0.0
Message-ID: <211516475.1248807569127.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade JBoss JAXR to 2.0.0
---------------------------

                 Key: JBAS-7127
                 URL: https://jira.jboss.org/jira/browse/JBAS-7127
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JAXR service
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: JBossAS-5.2.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 15:03:41 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 28 Jul 2009 15:03:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7127) Upgrade JBoss JAXR to
	2.0.0
In-Reply-To: <211516475.1248807569127.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1581925247.1248807821701.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBAS-7127.
-------------------------------

    Resolution: Done


anil at localhost:~/Branch_5_x$ svn ci -m "JBAS-7127: upgrade to JBoss JAXR 2.0.0" component-matrix/ testsuite/
Sending        component-matrix/pom.xml
Sending        testsuite/build.xml
Transmitting file data ..
Committed revision 91733.
anil at localhost:~/Branch_5_x$

> Upgrade JBoss JAXR to 2.0.0
> ---------------------------
>
>                 Key: JBAS-7127
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7127
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JAXR service
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 15:05:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 28 Jul 2009 15:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7128) JBoss 5.2.0
 Testsuite Failures Container Task
Message-ID: <827670661.1248807929533.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss 5.2.0 Testsuite Failures Container Task
---------------------------------------------

                 Key: JBAS-7128
                 URL: https://jira.jboss.org/jira/browse/JBAS-7128
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Anil Saldhana
            Assignee: Shelly McGowan
             Fix For: JBossAS-5.2.0.Beta1


Container Task for JBoss 5.2.0 Test Suite Failures.  Mainly for Branch_5_x.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 15:07:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 28 Jul 2009 15:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7129) Test Target
 tests-scout-jaxr failures
Message-ID: <860108443.1248808049353.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Test Target tests-scout-jaxr failures
-------------------------------------

                 Key: JBAS-7129
                 URL: https://jira.jboss.org/jira/browse/JBAS-7129
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JAXR service, Test Suite
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: JBossAS-5.2.0.Beta1




==============
tests-scout-jaxr:
    [mkdir] Created dir: /home/anil/Branch_5_x/testsuite/output/log
    [junit] Running org.jboss.test.jaxr.scout.JaxrBaseTestCase     
    [junit] Running org.jboss.test.jaxr.scout.JaxrBaseTestCase     
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.685 sec
    [junit] Running org.jboss.test.jaxr.scout.basic.JaxrJNDIConnectionTestCase
    [junit] Running org.jboss.test.jaxr.scout.basic.JaxrJNDIConnectionTestCase
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.354 sec     
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase
    [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 4.051 sec          
    [junit] Test org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase FAILED
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteOrganizationTestCase   
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteOrganizationTestCase   
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.898 sec              
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveOrganizationTestCase     
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveOrganizationTestCase     
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.687 sec              
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveServiceBindingTestCase   
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveServiceBindingTestCase   
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.705 sec              
    [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase
    [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase
    [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 2.193 sec                
    [junit] Test org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase FAILED
    [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrConfimAssociationTestCase
    [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrConfimAssociationTestCase
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.265 sec                    
    [junit] Running org.jboss.test.jaxr.scout.query.JaxrBusinessQueryTestCase                
    [junit] Running org.jboss.test.jaxr.scout.query.JaxrBusinessQueryTestCase                
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.187 sec                    
    [junit] Running org.jboss.test.jaxr.scout.query.infomodel.JaxrFindAssociationsTestCase   
    [junit] Running org.jboss.test.jaxr.scout.query.infomodel.JaxrFindAssociationsTestCase   
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.505 sec    
==================================

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 16:56:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Tue, 28 Jul 2009 16:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-1139) Modify PortUtil
 to allow a configurable range for MIN_UNPRIVILEGED_PORT and MAX_LEGAL_PORT.
In-Reply-To: <215395097.1246517211483.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2143727278.1248814589507.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBREM-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477964#action_12477964 ] 

Ron Sigal commented on JBREM-1139:
----------------------------------

The range from which PortUtil will choose ports may now be modified per JVM.

The parameters

 org.jboss.remoting.transport.PortUtil.MIN_PORT (actual value "minPort")
 org.jboss.remoting.transport.PortUtil.MAX_PORT (actual value "maxPort")

can be added to

 (1) the InvokerLocator,
 (2) a configuration map passed to org.jboss.remoting.Client or org.jboss.remoting.transport.Connector, or
 (3) the Connector's MBean definition

and they will be used to set the range used by PortUtil (determined by PortUtil.minPort and PortUtil.maxPort).  Note that PortUtil.minPort and PortUtil.maxPort are static values, so setting them affects all other clients and servers in the JVM.  Also, the values will be updated only if the resulting range is more restrictive.  I.e.,

 PortUtil.minPort == 3000  and  PortUtil.maxPort == 50000

can be updated to

 PortUtil.minPort == 4000  and  PortUtil.maxPort == 40000

but not to

 PortUtil.minPort == 2000 and  PortUtil.maxPort == 60000.

So far, the changes have been added to branch 2.2.  As usual in Remoting 2.2.x, the values in InvokerLocator take precedence over the values in the configuration map.

Unit tests:

  * org.jboss.test.remoting.util.PortUtilRangeOnClientTestCase
  * org.jboss.test.remoting.util.PortUtilRangeOnServerTestCase
  * org.jboss.test.remoting.util.PortUtilRangeOnServerWithXMLTestCase

Still have to apply changes to branch 2.x.

> Modify PortUtil to allow a configurable range for MIN_UNPRIVILEGED_PORT and MAX_LEGAL_PORT.
> -------------------------------------------------------------------------------------------
>
>                 Key: JBREM-1139
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1139
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.5.1 (Flounder), 2.2.3
>            Reporter: Colin Mondesir
>            Assignee: Ron Sigal
>             Fix For: 2.5.2 (Flounder), 2.2.3.SP1
>
>
> PortUtil could be improved to read the port range configuration.
> This is straightforward and no side effect is expected.  However,
> PortUtil and its callers will need some refactoring as it is just a
> static utility classes currently.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 17:00:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Tue, 28 Jul 2009 17:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-1143) CLONE [JBREM-877]
 - New Socket Connection is being Created for Every Client Request to the
 Server
In-Reply-To: <1703765675.1247253809257.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1458387550.1248814829313.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBREM-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477969#action_12477969 ] 

Ron Sigal commented on JBREM-1143:
----------------------------------

The changes have been  applied to the 2.2 branch.

Unit test:  org.jboss.test.remoting.invoke.ClientInvokerDelayedDestructionTestCase

Waiting for results in test suite.

> CLONE [JBREM-877] - New Socket Connection is being Created for Every Client Request to the Server
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBREM-1143
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1143
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 2.2.3
>            Reporter: Kumarselvan Somasundaram
>            Assignee: Ron Sigal
>             Fix For: 2.2.3.SP1
>
>
> JBREM-877 is being cloned to port the feature back to the 2.2 branch.  The original description:
> whenever  EJB3 client requests the Server new socket is being created. at the client side the socket connection pool is not being used. Hope there is some issue with the socket connection after getting response from the server,becoz of which the server side the connection is being closed. this increases the CPU utilization,
> The same code is running fine in jboss 4.0.4 with jboss remoting 1.4.0
> new remoting 2.2.2 SP4 only handling 1/4 of the load with high CPU utilization. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 18:49:29 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 28 Jul 2009 18:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (RELOADED-9) JNDI standardized
	namespaces
Message-ID: <907973659.1248821369136.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JNDI standardized namespaces
----------------------------

                 Key: RELOADED-9
                 URL: https://jira.jboss.org/jira/browse/RELOADED-9
             Project: JBoss Reloaded
          Issue Type: Feature Request
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 20:22:42 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 28 Jul 2009 20:22:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7130) Stack trace when
 starting up "all" configuration
Message-ID: <1446554410.1248826962724.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Stack trace when starting up "all" configuration
------------------------------------------------

                 Key: JBAS-7130
                 URL: https://jira.jboss.org/jira/browse/JBAS-7130
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JSF, Web (Tomcat) service
            Reporter: David Lloyd
            Assignee: Stan Silvert
             Fix For: JBossAS-6.0.0.Alpha1


I get the following stack trace when starting up in the "all" configuration:

19:19:07,154 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
19:19:07,187 WARNING [config] Unable to process deployment descriptor for context '/invoker': java.lang.IllegalArgumentException: InputStream cannot be null
	at javax.xml.parsers.SAXParser.parse(SAXParser.java:194)
	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.scanForFacesServlet(ConfigureListener.java:752)
	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.<init>(ConfigureListener.java:712)
	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:165)
	at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:60)
	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393)
	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
	at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:462)
	at org.jboss.web.deployers.WebModule.startModule(WebModule.java:116)
	at org.jboss.web.deployers.WebModule.start(WebModule.java:95)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
	at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:207)
	at $Proxy38.start(Unknown Source)
	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
	at org.jboss.system.ServiceController.start(ServiceController.java:443)
	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
	at org.jboss.system.ServiceController.start(ServiceController.java:443)
	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.system.ServiceController.doInstall(ServiceController.java:653)
	at org.jboss.system.ServiceController.register(ServiceController.java:356)
	at org.jboss.system.microcontainer.jmx.ServiceControllerRegistrationLifecycleCallback.install(ServiceControllerRegistrationLifecycleCallback.java:104)
	at sun.reflect.GeneratedMethodAccessor239.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
	at org.jboss.system.ServiceController.start(ServiceController.java:443)
	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 20:39:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 28 Jul 2009 20:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBLOGGING-22) Log file is
 randomly truncated when configured from JBossMC/JBossAS
In-Reply-To: <30688019.1248726089233.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1069168884.1248827969291.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBLOGGING-22.
--------------------------------

    Resolution: Done


> Log file is randomly truncated when configured from JBossMC/JBossAS
> -------------------------------------------------------------------
>
>                 Key: JBLOGGING-22
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-22
>             Project: JBoss Logging
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logmanager
>    Affects Versions: 1.1.0.CR4-jboss-logmanager
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 1.1.0.CR5-jboss-logmanager
>
>
> Due to strangeness in the way that JBossMC's BeanMetaDataBuilder.addProperty() method works, the file name of the rotating file handlers is sometimes (but not always) set before the append flag, causing the file to be truncated even if append was set to true.
> Add constructors such that both properties can be set simultaneously to work around this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 21:36:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 28 Jul 2009 21:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-23) Add support for
 internationalization and localization with parameterized messages
Message-ID: <731548133.1248831389259.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add support for internationalization and localization with parameterized messages
---------------------------------------------------------------------------------

                 Key: JBLOGGING-23
                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-23
             Project: JBoss Logging
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: jboss-logging-jdk, jboss-logging-log4j, jboss-logging-spi
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 2.2.0.CR1-jboss-logging


The logging API should support optional parameters E.g.:

    /**
     * Issue a log message with parameters and a throwable with a level of TRACE.
     *
     * @param loggerFqcn the logger class name
     * @param message the message
     * @param params the message parameters
     * @param t the throwable
     */
   public void trace(String loggerFqcn, Object message, Object[] params, Throwable t) { ... }

The logger factory method should allow specification of a resource bundle, e.g.:

   Logger getLogger(String category, String resourceBundleName) { ... }


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 28 21:38:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 28 Jul 2009 21:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-24) Add ability to
 cache logger instances
Message-ID: <109580682.1248831509140.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add ability to cache logger instances
-------------------------------------

                 Key: JBLOGGING-24
                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-24
             Project: JBoss Logging
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: jboss-logging-jdk, jboss-logging-log4j, jboss-logging-spi
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 2.2.0.CR1-jboss-logging


The present API/SPI does not allow logger instances to be cached and reused, which can cause unnecessary memory pressure by creating many identical objects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 02:10:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 29 Jul 2009 02:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1649489172.1248847829251.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478012#action_12478012 ] 

Howard Gao commented on JBMESSAGING-1685:
-----------------------------------------

Hi Martin,

If I didn't understand wrong, the problem is that there is too much messages in the DLQ and this caused OOM. The DLQ is just like any other queues in JBM, which will holds messages that are sent to it. To control the memory usage of a queue, you can limit the number of messages that reside in memory by specifying fullSize/pageSize/downCacheSize attributes of the queue. Any more messages that exceed the fullSize will be stored to DB and later will be loaded as the messages are being delivered off. 

The properties are described in the JBM doc. Please try it and see if the OOM is gone.

> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java, QueueExampleLong.java, QueueExampleLong2.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 03:15:29 2009
From: jira-events at lists.jboss.org (Bernard de Terwangne (JIRA))
Date: Wed, 29 Jul 2009 03:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2436) JBPC 2.0 :
 ResourceResponse.setCharacterEncoding always throws
 UnsupportedOperationException
Message-ID: <663297249.1248851729342.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBPC 2.0 : ResourceResponse.setCharacterEncoding always throws UnsupportedOperationException
--------------------------------------------------------------------------------------------

                 Key: JBPORTAL-2436
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2436
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: Portlet-2.0
         Environment: Any
            Reporter: Bernard de Terwangne


package org.jboss.portal.portlet.impl.jsr168.api;

...

public class ResourceResponseImpl extends MimeResponseImpl implements ResourceResponse
{
...
   public void setLocale(Locale locale)
   {
      throw new UnsupportedOperationException();
   }

   public void setCharacterEncoding(String s)
   {
      throw new UnsupportedOperationException();
   }

   public void setContentLength(int i)
   {
      throw new UnsupportedOperationException();
   }

...
}

Problems come when you want to deploy your portlet on JBoss PortletContainer and on other portals. JSR-286 does not state that portals my throw UnsupportedOperationException.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 04:57:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Wed, 29 Jul 2009 04:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-113) Support standard
 303 validation annotation
In-Reply-To: <713920493.1247472449189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2076600072.1248857849139.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved JBJCA-113.
------------------------------

    Resolution: Done


> Support standard 303 validation annotation
> ------------------------------------------
>
>                 Key: JBJCA-113
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-113
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> *) ra16standard303.rar (Valid (@NotNull) - must be deployed)
> Create a resource adapter in deployer/test that uses standard 303 defined 
> tags like @NotNull and @Min

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 05:01:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Wed, 29 Jul 2009 05:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-114) Support custom 303
 validation annotation
In-Reply-To: <940958141.1247472580910.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1139792308.1248858089296.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved JBJCA-114.
------------------------------

    Resolution: Done


> Support custom 303 validation annotation
> ----------------------------------------
>
>                 Key: JBJCA-114
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-114
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> *) ra16user303.rar (Valid (@FrenchZipcode) - must be deployed)
> Create a resource adapter in deployer/test that uses custom defined tags - 
> an example would be @FrenchZipcode from the 303 spec. The resource adapter 
> must of course include the classes needed to make this happen

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 05:01:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Wed, 29 Jul 2009 05:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-116) Negative test for
 custom 303 validation annotation
In-Reply-To: <673733390.1247472809337.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <153965379.1248858089386.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved JBJCA-116.
------------------------------

    Resolution: Done


> Negative test for custom 303 validation annotation
> --------------------------------------------------
>
>                 Key: JBJCA-116
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-116
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> ra16user303jbossra.rar (Invalid - must fail)
> define in ra.xml and override in jboss-ra.xml, validate should be fail

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 05:01:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Wed, 29 Jul 2009 05:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-115) Negative test for
 standard 303 validation annotation
In-Reply-To: <1562454476.1247472809212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1172956974.1248858089480.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved JBJCA-115.
------------------------------

    Resolution: Done


> Negative test for standard 303 validation annotation
> ----------------------------------------------------
>
>                 Key: JBJCA-115
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-115
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> ra16standard303jbossra.rar (Invalid - must fail)
> define in ra.xml and override in jboss-ra.xml, validate should be fail

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 05:40:29 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 29 Jul 2009 05:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-70) Allow multiple
 @Management interfaces for a @Service bean
Message-ID: <58351899.1248860429777.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved EJBTHREE-70.
-----------------------------------

    Resolution: Won't Fix
      Assignee: Carlo de Wolf  (was: Bill Burke)


> Allow multiple @Management interfaces for a @Service bean
> ---------------------------------------------------------
>
>                 Key: EJBTHREE-70
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-70
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: Preview 3
>            Reporter: Kabir Khan
>            Assignee: Carlo de Wolf
>
> See http://jira.jboss.com/jira/browse/EJBTHREE-65

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 06:07:29 2009
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Wed, 29 Jul 2009 06:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2437) Remove
 hard-coded context path references
Message-ID: <1997590605.1248862049393.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Remove hard-coded context path references
-----------------------------------------

                 Key: JBPORTAL-2437
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2437
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.7.2 Final
            Reporter: Martin Putz
            Assignee: Thomas Heute


All portal contexts should be configurable to share a common context. For this to work, we customized our jboss portal installation changing the context path. We modified following files:

./portal-admin.sar/portal-admin.war/WEB-INF/jboss-web.xml
./portal-ajax.war/WEB-INF/jboss-web.xml
./portal-cms.sar/portal-cms.war/WEB-INF/jboss-web.xml
./portal-core.war/WEB-INF/jboss-web.xml
./portal-identity.sar/portal-identity.war/WEB-INF/jboss-web.xml
./portal-server.war/WEB-INF/jboss-web.xml
./portal-widget-netvibes.war/WEB-INF/jboss-web.xml
./portal-widget.war/WEB-INF/jboss-web.xml
./portal-wsrp.sar/portal-wsrp-admin.war/WEB-INF/jboss-web.xml
./portal-wsrp.sar/portal-wsrp.war/WEB-INF/jboss-web.xml
./samples/portal-jsp-samples.war/WEB-INF/jboss-web.xml
./samples/portal-news-samples.war/WEB-INF/jboss-web.xml
./samples/portal-portlet-samples.war/WEB-INF/jboss-web.xml
./samples/portal-users-samples.sar/portal-users-samples.war/WEB-INF/jboss-web.xml

For example, the file ./portal-admin.sar/portal-admin.war/WEB-INF/jboss-web.xml has been modified in the following way:

<jboss-web>
       <context-root>/portal/portal-admin</context-root>
</jboss-web>

The file ./portal-core.war/WEB-INF/jboss-web.xml became:

<jboss-web>
       <context-root>/portal/portal-core</context-root>
</jboss-web>

As the default context names are hard-coded in some references, a couple of links are corrupted like this:

<img src="/portal-core/images/portletIcon_Default1.gif" alt="icon" align="middle" style="margin:0 4px 0 0" />

The context path should not be hard-coded in the sources.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 07:40:29 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Wed, 29 Jul 2009 07:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
In-Reply-To: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2099188738.1248867629815.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1693:
--------------------------------------

    Attachment: JMSConsumer.java


> Unable to consume more than  777,000 messages
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1693
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>         Environment: Windows Vista, 32 bit, 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>            Priority: Critical
>         Attachments: JMSBase.java, JMSConsumer.java, JMSSender.java, src.rar, TestCunsumer.java, TestSender.java
>
>
> Using messaging-2.0.0.BETA3 stand alone non-clustered
> -------------------------------------------------------------------------------
> I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
>  <global-page-size>10485760</global-page-size>
> <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 
> Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
> -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
> Please find the attached java files. Test instructions are given below
> 1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
> 2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
> 3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
> 4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
> 5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
> Messages Consumed = messagesAdded -  MessageCount  
>  a) 800246 - 23246 = 777000
>  b) 799037 - 22037 = 777000
>  c)  799037 - 22037 = 777000
> It seems the number of messages consumed (777000 in above case) is driven by message size (and Queue size).  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 07:40:29 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Wed, 29 Jul 2009 07:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
In-Reply-To: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <224204782.1248867629647.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1693:
--------------------------------------

    Attachment: JMSBase.java


> Unable to consume more than  777,000 messages
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1693
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>         Environment: Windows Vista, 32 bit, 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>            Priority: Critical
>         Attachments: JMSBase.java, JMSConsumer.java, JMSSender.java, src.rar, TestCunsumer.java, TestSender.java
>
>
> Using messaging-2.0.0.BETA3 stand alone non-clustered
> -------------------------------------------------------------------------------
> I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
>  <global-page-size>10485760</global-page-size>
> <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 
> Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
> -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
> Please find the attached java files. Test instructions are given below
> 1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
> 2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
> 3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
> 4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
> 5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
> Messages Consumed = messagesAdded -  MessageCount  
>  a) 800246 - 23246 = 777000
>  b) 799037 - 22037 = 777000
>  c)  799037 - 22037 = 777000
> It seems the number of messages consumed (777000 in above case) is driven by message size (and Queue size).  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 07:40:29 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Wed, 29 Jul 2009 07:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
In-Reply-To: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <633735148.1248867629944.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1693:
--------------------------------------

    Attachment: JMSSender.java


> Unable to consume more than  777,000 messages
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1693
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>         Environment: Windows Vista, 32 bit, 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>            Priority: Critical
>         Attachments: JMSBase.java, JMSConsumer.java, JMSSender.java, src.rar, TestCunsumer.java, TestSender.java
>
>
> Using messaging-2.0.0.BETA3 stand alone non-clustered
> -------------------------------------------------------------------------------
> I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
>  <global-page-size>10485760</global-page-size>
> <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 
> Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
> -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
> Please find the attached java files. Test instructions are given below
> 1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
> 2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
> 3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
> 4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
> 5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
> Messages Consumed = messagesAdded -  MessageCount  
>  a) 800246 - 23246 = 777000
>  b) 799037 - 22037 = 777000
>  c)  799037 - 22037 = 777000
> It seems the number of messages consumed (777000 in above case) is driven by message size (and Queue size).  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 07:40:30 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Wed, 29 Jul 2009 07:40:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
In-Reply-To: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <773841589.1248867630098.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1693:
--------------------------------------

    Attachment: TestCunsumer.java


> Unable to consume more than  777,000 messages
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1693
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>         Environment: Windows Vista, 32 bit, 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>            Priority: Critical
>         Attachments: JMSBase.java, JMSConsumer.java, JMSSender.java, src.rar, TestCunsumer.java, TestSender.java
>
>
> Using messaging-2.0.0.BETA3 stand alone non-clustered
> -------------------------------------------------------------------------------
> I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
>  <global-page-size>10485760</global-page-size>
> <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 
> Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
> -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
> Please find the attached java files. Test instructions are given below
> 1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
> 2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
> 3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
> 4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
> 5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
> Messages Consumed = messagesAdded -  MessageCount  
>  a) 800246 - 23246 = 777000
>  b) 799037 - 22037 = 777000
>  c)  799037 - 22037 = 777000
> It seems the number of messages consumed (777000 in above case) is driven by message size (and Queue size).  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 07:40:30 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Wed, 29 Jul 2009 07:40:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
In-Reply-To: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <433037665.1248867630223.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1693:
--------------------------------------

    Attachment: TestSender.java


> Unable to consume more than  777,000 messages
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1693
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>         Environment: Windows Vista, 32 bit, 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>            Priority: Critical
>         Attachments: JMSBase.java, JMSConsumer.java, JMSSender.java, src.rar, TestCunsumer.java, TestSender.java
>
>
> Using messaging-2.0.0.BETA3 stand alone non-clustered
> -------------------------------------------------------------------------------
> I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
>  <global-page-size>10485760</global-page-size>
> <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 
> Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
> -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
> Please find the attached java files. Test instructions are given below
> 1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
> 2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
> 3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
> 4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
> 5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
> Messages Consumed = messagesAdded -  MessageCount  
>  a) 800246 - 23246 = 777000
>  b) 799037 - 22037 = 777000
>  c)  799037 - 22037 = 777000
> It seems the number of messages consumed (777000 in above case) is driven by message size (and Queue size).  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 08:14:29 2009
From: jira-events at lists.jboss.org (Aleksander Adamowski (JIRA))
Date: Wed, 29 Jul 2009 08:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (BPEL-307) Migrate CVS source
 repository to SVN
Message-ID: <1671862215.1248869669304.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Migrate CVS source repository to SVN
------------------------------------

                 Key: BPEL-307
                 URL: https://jira.jboss.org/jira/browse/BPEL-307
             Project: JBoss jBPM BPEL
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Aleksander Adamowski
            Assignee: Alejandro Guizar


The jBPM-BPEL sources are hard to find because, unlike almost all other JBoss projects (including jBPM), they are not hosted in SVN on the main JBoss server (http://svn.jboss.org/repos/).


The page http://jboss.org/jbossjbpm/bpel_sources/ gives info about how to check out the sources from CVS.

However, this requires outgoing access to port 2401 and from some firewalled environtments where outside access is only possible through a HTTP proxy the CVS repository is inaccessible. Also, CVS is a version control system vastly inferior to SVN.

Therefore, JBoss jBPM-BPEL source repository should be migrated to SVN.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 08:32:29 2009
From: jira-events at lists.jboss.org (Daniel Bevenius (JIRA))
Date: Wed, 29 Jul 2009 08:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7132)
 shutdown.sh/shutdown.bat is missing jars in its classpath which causes
 NoClassDefFoundError(s)
Message-ID: <1226982325.1248870749134.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

shutdown.sh/shutdown.bat is missing jars in its classpath which causes NoClassDefFoundError(s) 
-----------------------------------------------------------------------------------------------

                 Key: JBAS-7132
                 URL: https://jira.jboss.org/jira/browse/JBAS-7132
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Daniel Bevenius
            Priority: Minor


Currently the server/src/bin/shutdown.sh contains only two jars:
JBOSS_BOOT_CLASSPATH="$JBOSS_HOME/bin/shutdown.jar:$JBOSS_HOME/client/jbossall-client.jar"
and as far as I can tell it requires:
JBOSS_BOOT_CLASSPATH="$JBOSS_HOME/bin/shutdown.jar:$JBOSS_HOME/client/jbossall-client.jar:$JBOSS_HOME/lib/jboss-bootstrap-spi-as.jar:$JBOSS_HOME/lib/jboss-bootstrap-spi-mc.jar:$JBOSS_HOME/lib/jboss-bootstrap-spi.jar:$JBOSS_HOME/lib/jboss-system-jmx.jar:$JBOSS_HOME/lib/jboss-kernel.jar"

If you like feel free to assign this to me.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 08:49:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 29 Jul 2009 08:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1016) memory leak in GMS
	protocol
In-Reply-To: <1523793676.1248774569291.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <196368678.1248871769182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1016:
---------------------------

    Fix Version/s: 2.6.11
                   2.8
         Priority: Major  (was: Critical)


> memory leak in GMS protocol
> ---------------------------
>
>                 Key: JGRP-1016
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1016
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>            Reporter: Miro Selent
>            Assignee: Bela Ban
>             Fix For: 2.6.11, 2.8
>
>
> Found in org.jgroups.protocols.pbcast.GMS in a scenario where members were killed and restarted very frequently and one member is persistently running. The memory consumption icreased very quickly until OutOfMemory.
> Our analysis with JProfiler leads to the following assumption:
> The number of org.jgroups.stack.IpAddress held by merge_ack_collector icreases every time a member was (re)started. 
> These instances were never removed because no MERGE events occured. This is completely clear since there was only one coordinator (the long running member). 
> If GMS receives no MERGE event it never cleans up the stored IpAddress instances in the merge_ack_collector.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 09:50:29 2009
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 29 Jul 2009 09:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2356) It is
 impossible to use html forms in portlets or js to build http request
In-Reply-To: <10202950.1238084123266.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <723706396.1248875429466.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478064#action_12478064 ] 

Thomas Heute commented on JBPORTAL-2356:
----------------------------------------

In order to apply your patch I would need you to sign the contributor agreement if possible:
https://www.jboss.org/contribute/

Thanks !

> It is impossible to use html forms in portlets or js to build http request
> --------------------------------------------------------------------------
>
>                 Key: JBPORTAL-2356
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2356
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: Portlet-2.0.1
>         Environment: Linux, Java 5, Tomcat, JBoss Portlet Container 2.0
>            Reporter: Bernard de Terwangne
>         Attachments: ControllerRequestFactory.java, ControllerRequestFactory.java, ControllerRequestFactoryTestCase.java
>
>
> JBoss Portlet container conforms to the spec so well that it becomes unusable. It is impossible to query the end-user for a value and pass that value in processAction or serveResource calls. Let's say you write this in your JSP page :
> <form action="<portlet:actionURL><portlet:param name='q' value='yop'/></portlet:actionURL">
> <input name="q" type="text/>
> <input type="submit"/>
> </form>
> and in the Java code
> 	public void processAction(ActionRequest req, ActionResponse res)
> 			throws IOException, PortletException {
> 		System.out.println(req.getParameter("q");
>         }
> The printed value will allways be "yop" (the value placed in the portlet:param tag. There is no way to retrieve the value actually typed by the end user.
> This is due to the fact JBoss Portlet container mangles in Base64 the parameters from <portlet:param> and disregards parameters appended by the browser's form implementation. Same thing with <resourceURL>. There is no way to pass user input to the portlet's Java code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 10:06:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 10:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-130) SJC: Wrap all
 deployment exceptions in DeployException
Message-ID: <1971953316.1248876389209.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC: Wrap all deployment exceptions in DeployException
------------------------------------------------------

                 Key: JBJCA-130
                 URL: https://jira.jboss.org/jira/browse/JBJCA-130
             Project: JBoss JCA
          Issue Type: Task
          Components: Standalone
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 10:06:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 10:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-130) SJC: Wrap all
 deployment exceptions in DeployException
In-Reply-To: <1971953316.1248876389209.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1959391779.1248876389284.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-130.
-----------------------------------

    Resolution: Done


> SJC: Wrap all deployment exceptions in DeployException
> ------------------------------------------------------
>
>                 Key: JBJCA-130
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-130
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Standalone
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 10:48:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 10:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-118) SJC/RADeployer:
 Merge specification and vendor metadata
In-Reply-To: <369789920.1247765680901.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <906542183.1248878909796.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-118.
-----------------------------------

    Resolution: Done


> SJC/RADeployer: Merge specification and vendor metadata
> -------------------------------------------------------
>
>                 Key: JBJCA-118
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-118
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Merge the metadata from the specification (ConnectorMetaData) with our metadata (JBossRAMetaData).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 10:52:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 10:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-102) SJC/RADeployer:
 Merge annotations and metadata
In-Reply-To: <2016998490.1246458231392.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <973935655.1248879149231.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-102:
----------------------------------

    Fix Version/s: 1.0.0.Alpha3
                       (was: 1.0.0.Alpha2)


> SJC/RADeployer: Merge annotations and metadata
> ----------------------------------------------
>
>                 Key: JBJCA-102
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-102
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha3
>
>
> Merge the metadata from the XML and the annotations into a single model.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 10:52:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 10:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-123) Update logging
	framework
In-Reply-To: <1781074719.1248718062317.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <251184603.1248879149381.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-123.
-----------------------------------

    Resolution: Done


> Update logging framework
> ------------------------
>
>                 Key: JBJCA-123
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-123
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Build, Standalone
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Update the logging framework to use JBoss LogManager 1.1 and dependant libraries.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 11:53:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 29 Jul 2009 11:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6918) "trackByTxn"
 always gets displayed as "false" in the output of the "listStatistics"
 operation for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <552196278.1248882809818.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478095#action_12478095 ] 

Ian Springer commented on JBAS-6918:
------------------------------------

Note, I think the "track-connection-by-tx" prop is deprecated, at least in some cases (see https://jira.jboss.org/jira/browse/JBAS-5203).


> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 11:53:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Jul 2009 11:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1601) Cache Large
 Message body on Client
In-Reply-To: <12004607.1239904702467.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <951643740.1248882809931.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1601:
-----------------------------------------

       Summary: Cache Large Message body on Client  (was: JMSBridge won't work with LargeMessages and resend)
    Issue Type: Feature Request  (was: Bug)


> Cache Large Message body on Client
> ----------------------------------
>
>                 Key: JBMESSAGING-1601
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1601
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> The JMS Bridge is caching a Message, and resending it when a failure occurs.
> On the case of a LargeMessage, the message should be received again instead of cached.
> Actually caching won't work with LargeMessages at all.
> There should be a config on JMSBridge that would complete disable caching, and the message would be received again in case of failure on either side (src or dest address). The user would need then to configure the JMSBridge accordingly to LargeMessages if that feature is being used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 11:53:30 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Jul 2009 11:53:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1601) Cache Large
 Message body on Client
In-Reply-To: <12004607.1239904702467.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1230533959.1248882810068.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1601.
----------------------------------------

    Resolution: Done


> Cache Large Message body on Client
> ----------------------------------
>
>                 Key: JBMESSAGING-1601
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1601
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> The JMS Bridge is caching a Message, and resending it when a failure occurs.
> On the case of a LargeMessage, the message should be received again instead of cached.
> Actually caching won't work with LargeMessages at all.
> There should be a config on JMSBridge that would complete disable caching, and the message would be received again in case of failure on either side (src or dest address). The user would need then to configure the JMSBridge accordingly to LargeMessages if that feature is being used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 11:59:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Wed, 29 Jul 2009 11:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6918) "trackByTxn"
 always gets displayed as "false" in the output of the "listStatistics"
 operation for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1582973289.1248883169491.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478098#action_12478098 ] 

Charles Crouch commented on JBAS-6918:
--------------------------------------

Jason to determine whether "track-connection-by-tx" is deprecated or not.
One option is just to drop the "trackByTxn" property from the operation

> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 11:59:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Wed, 29 Jul 2009 11:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6918) "trackByTxn" always
 gets displayed as "false" in the output of the "listStatistics" operation
 for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <47265925.1248883169661.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch reassigned JBAS-6918:
------------------------------------

    Assignee: Jason T. Greene  (was: Scott M Stark)


> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Jason T. Greene
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:01:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-131) SJC: Create resource
 adapter object
Message-ID: <1786446646.1248886889184.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC: Create resource adapter object
-----------------------------------

                 Key: JBJCA-131
                 URL: https://jira.jboss.org/jira/browse/JBJCA-131
             Project: JBoss JCA
          Issue Type: Task
          Components: Standalone
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Create the resource adapter object and inject all its property values.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:03:41 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:03:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-131) SJC: Create
 resource adapter object
In-Reply-To: <1786446646.1248886889184.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1009696296.1248887021035.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-131.
-----------------------------------

    Resolution: Done


> SJC: Create resource adapter object
> -----------------------------------
>
>                 Key: JBJCA-131
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-131
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Standalone
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Create the resource adapter object and inject all its property values.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:07:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 13:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7129) Test Target
 tests-scout-jaxr failures
In-Reply-To: <860108443.1248808049353.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <245439249.1248887249168.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478105#action_12478105 ] 

Anil Saldhana commented on JBAS-7129:
-------------------------------------

Dependent on the fix of https://issues.apache.org/jira/browse/SCOUT-88

> Test Target tests-scout-jaxr failures
> -------------------------------------
>
>                 Key: JBAS-7129
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7129
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JAXR service, Test Suite
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> ==============
> tests-scout-jaxr:
>     [mkdir] Created dir: /home/anil/Branch_5_x/testsuite/output/log
>     [junit] Running org.jboss.test.jaxr.scout.JaxrBaseTestCase     
>     [junit] Running org.jboss.test.jaxr.scout.JaxrBaseTestCase     
>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.685 sec
>     [junit] Running org.jboss.test.jaxr.scout.basic.JaxrJNDIConnectionTestCase
>     [junit] Running org.jboss.test.jaxr.scout.basic.JaxrJNDIConnectionTestCase
>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.354 sec     
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase
>     [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 4.051 sec          
>     [junit] Test org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase FAILED
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteOrganizationTestCase   
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteOrganizationTestCase   
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.898 sec              
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveOrganizationTestCase     
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveOrganizationTestCase     
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.687 sec              
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveServiceBindingTestCase   
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveServiceBindingTestCase   
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.705 sec              
>     [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase
>     [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase
>     [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 2.193 sec                
>     [junit] Test org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase FAILED
>     [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrConfimAssociationTestCase
>     [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrConfimAssociationTestCase
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.265 sec                    
>     [junit] Running org.jboss.test.jaxr.scout.query.JaxrBusinessQueryTestCase                
>     [junit] Running org.jboss.test.jaxr.scout.query.JaxrBusinessQueryTestCase                
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.187 sec                    
>     [junit] Running org.jboss.test.jaxr.scout.query.infomodel.JaxrFindAssociationsTestCase   
>     [junit] Running org.jboss.test.jaxr.scout.query.infomodel.JaxrFindAssociationsTestCase   
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.505 sec    
> ==================================

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-109) Cobertura 1.9.2
In-Reply-To: <2038758232.1246905891403.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <627876090.1248887490287.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-109.
-----------------------------------

    Resolution: Done


> Cobertura 1.9.2
> ---------------
>
>                 Key: JBJCA-109
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-109
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-119) Hibernate Validator
	4.0.0.Beta2
In-Reply-To: <1098713284.1247792429189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <721520686.1248887490437.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-119.
-----------------------------------

    Resolution: Done


> Hibernate Validator 4.0.0.Beta2
> -------------------------------
>
>                 Key: JBJCA-119
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-119
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> for 303 requirement 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-120) Validation API
	1.0.CR3
In-Reply-To: <105271748.1248261929139.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1359600549.1248887490543.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-120.
-----------------------------------

    Resolution: Done


> Validation API 1.0.CR3
> ----------------------
>
>                 Key: JBJCA-120
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-120
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-121) SLF4J 1.5.6
In-Reply-To: <490362193.1248717809672.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <474286597.1248887490659.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-121.
-----------------------------------

    Resolution: Done


> SLF4J 1.5.6
> -----------
>
>                 Key: JBJCA-121
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-121
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-125) JBoss Classloading
	2.0.6.GA
In-Reply-To: <827060506.1248720089293.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <748193138.1248887490738.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-125.
-----------------------------------

    Resolution: Done


> JBoss Classloading 2.0.6.GA
> ---------------------------
>
>                 Key: JBJCA-125
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-125
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-99) Track component
	updates
In-Reply-To: <1859063348.1246366712646.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <46879599.1248887490087.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-99.
----------------------------------

    Resolution: Done


> Track component updates
> -----------------------
>
>                 Key: JBJCA-99
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-99
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Track component updates for 1.0.0.Alpha2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-103) Javassist 3.11 GA
In-Reply-To: <1839914087.1246561131576.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1141112271.1248887490181.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-103.
-----------------------------------

    Resolution: Done


> Javassist 3.11 GA
> -----------------
>
>                 Key: JBJCA-103
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-103
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-126) JBoss Deployer
	2.0.8.GA
In-Reply-To: <290360875.1248720089360.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1387564072.1248887490829.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-126.
-----------------------------------

    Resolution: Done


> JBoss Deployer 2.0.8.GA
> -----------------------
>
>                 Key: JBJCA-126
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-126
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-127) JBoss MC Dependency
	2.0.8.GA
In-Reply-To: <1297570986.1248720089465.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1451725980.1248887490904.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-127.
-----------------------------------

    Resolution: Done


> JBoss MC Dependency 2.0.8.GA
> ----------------------------
>
>                 Key: JBJCA-127
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-127
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-128) JBoss MC Kernel
	2.0.8.GA
In-Reply-To: <1869359378.1248720209164.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1315733851.1248887490984.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-128.
-----------------------------------

    Resolution: Done


> JBoss MC Kernel 2.0.8.GA
> ------------------------
>
>                 Key: JBJCA-128
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-128
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:11:31 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-129) JBoss VFS 2.1.2.GA
In-Reply-To: <1486842312.1248720209260.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1720983048.1248887491093.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-129.
-----------------------------------

    Resolution: Done


> JBoss VFS 2.1.2.GA
> ------------------
>
>                 Key: JBJCA-129
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-129
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:22:29 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Wed, 29 Jul 2009 13:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-91) More modular
	packaging
Message-ID: <261113433.1248888149149.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

More modular packaging
----------------------

                 Key: JASSIST-91
                 URL: https://jira.jboss.org/jira/browse/JASSIST-91
             Project: Javassist
          Issue Type: Feature Request
            Reporter: Pete Muir
            Assignee: Shigeru Chiba
            Priority: Optional


It would great if you could just take the bits of Javassist you need - for example, we only ever use the proxy generation facility, and don't need any of the bytecode generation.

Motivation is simple - smaller dependencies (in jar file size).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:36:41 2009
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Wed, 29 Jul 2009 13:36:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6771) Typo in log message
 of WebServiceDeployerEJB.internalDeploy()
In-Reply-To: <15110409.1239539482895.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2125874086.1248889001479.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated JBAS-6771:
----------------------------------

    Assignee: Richard Opalka  (was: Alessio Soldano)


Richard, fix this comment typo if it's still there while merging your work on deployers to the trunk.

> Typo in log message of WebServiceDeployerEJB.internalDeploy()
> -------------------------------------------------------------
>
>                 Key: JBAS-6771
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6771
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-5.0.1.GA
>            Reporter: Hiranya Samarasekera
>            Assignee: Richard Opalka
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The word "Ignore" is mistyped as "Ingore" in the log message in method internalDeploy()
> log.warn("Ingore ejb deployment with null classname: " + ejb);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:36:41 2009
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Wed, 29 Jul 2009 13:36:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6771) Typo in log message
 of WebServiceDeployerEJB.internalDeploy()
In-Reply-To: <15110409.1239539482895.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2007219964.1248889001847.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated JBAS-6771:
----------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> Typo in log message of WebServiceDeployerEJB.internalDeploy()
> -------------------------------------------------------------
>
>                 Key: JBAS-6771
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6771
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-5.0.1.GA
>            Reporter: Hiranya Samarasekera
>            Assignee: Richard Opalka
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The word "Ignore" is mistyped as "Ingore" in the log message in method internalDeploy()
> log.warn("Ingore ejb deployment with null classname: " + ejb);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:40:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 29 Jul 2009 13:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7130) Stack trace when
 starting up "all" configuration
In-Reply-To: <1446554410.1248826962724.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <25241547.1248889229328.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478115#action_12478115 ] 

Stan Silvert commented on JBAS-7130:
------------------------------------

This is a bug in Mojarra:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1224

For now, you can work around the problem by placing an empty web.xml file in server/all/deploy/httpha-invoker.sar/invoker.war/WEB-INF

Once we get the JSF Deployer finished, this won't matter because Mojarra won't get called unless a FacesServlet exists in web.xml metadata.

> Stack trace when starting up "all" configuration
> ------------------------------------------------
>
>                 Key: JBAS-7130
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7130
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF, Web (Tomcat) service
>            Reporter: David Lloyd
>            Assignee: Stan Silvert
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> I get the following stack trace when starting up in the "all" configuration:
> 19:19:07,154 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
> 19:19:07,187 WARNING [config] Unable to process deployment descriptor for context '/invoker': java.lang.IllegalArgumentException: InputStream cannot be null
> 	at javax.xml.parsers.SAXParser.parse(SAXParser.java:194)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.scanForFacesServlet(ConfigureListener.java:752)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.<init>(ConfigureListener.java:712)
> 	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:165)
> 	at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:60)
> 	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
> 	at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:462)
> 	at org.jboss.web.deployers.WebModule.startModule(WebModule.java:116)
> 	at org.jboss.web.deployers.WebModule.start(WebModule.java:95)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:207)
> 	at $Proxy38.start(Unknown Source)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:653)
> 	at org.jboss.system.ServiceController.register(ServiceController.java:356)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerRegistrationLifecycleCallback.install(ServiceControllerRegistrationLifecycleCallback.java:104)
> 	at sun.reflect.GeneratedMethodAccessor239.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:42:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 29 Jul 2009 13:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7130) Stack trace when
 starting up "all" configuration
In-Reply-To: <1446554410.1248826962724.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <891337156.1248889349301.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert updated JBAS-7130:
-------------------------------

    Workaround Description: Place an empty web.xml file in server/all/deploy/httpha-invoker.sar/invoker.war/WEB-INF


> Stack trace when starting up "all" configuration
> ------------------------------------------------
>
>                 Key: JBAS-7130
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7130
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF, Web (Tomcat) service
>            Reporter: David Lloyd
>            Assignee: Stan Silvert
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> I get the following stack trace when starting up in the "all" configuration:
> 19:19:07,154 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
> 19:19:07,187 WARNING [config] Unable to process deployment descriptor for context '/invoker': java.lang.IllegalArgumentException: InputStream cannot be null
> 	at javax.xml.parsers.SAXParser.parse(SAXParser.java:194)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.scanForFacesServlet(ConfigureListener.java:752)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.<init>(ConfigureListener.java:712)
> 	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:165)
> 	at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:60)
> 	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
> 	at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:462)
> 	at org.jboss.web.deployers.WebModule.startModule(WebModule.java:116)
> 	at org.jboss.web.deployers.WebModule.start(WebModule.java:95)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:207)
> 	at $Proxy38.start(Unknown Source)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:653)
> 	at org.jboss.system.ServiceController.register(ServiceController.java:356)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerRegistrationLifecycleCallback.install(ServiceControllerRegistrationLifecycleCallback.java:104)
> 	at sun.reflect.GeneratedMethodAccessor239.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 13:55:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 13:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7130) Stack trace when
 starting up "all" configuration
In-Reply-To: <1446554410.1248826962724.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1340972933.1248890129331.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478117#action_12478117 ] 

David Lloyd commented on JBAS-7130:
-----------------------------------

OK, cool.  Just wanted to make sure that this was reported.

> Stack trace when starting up "all" configuration
> ------------------------------------------------
>
>                 Key: JBAS-7130
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7130
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF, Web (Tomcat) service
>            Reporter: David Lloyd
>            Assignee: Stan Silvert
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> I get the following stack trace when starting up in the "all" configuration:
> 19:19:07,154 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
> 19:19:07,187 WARNING [config] Unable to process deployment descriptor for context '/invoker': java.lang.IllegalArgumentException: InputStream cannot be null
> 	at javax.xml.parsers.SAXParser.parse(SAXParser.java:194)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.scanForFacesServlet(ConfigureListener.java:752)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.<init>(ConfigureListener.java:712)
> 	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:165)
> 	at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:60)
> 	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
> 	at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:462)
> 	at org.jboss.web.deployers.WebModule.startModule(WebModule.java:116)
> 	at org.jboss.web.deployers.WebModule.start(WebModule.java:95)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:207)
> 	at $Proxy38.start(Unknown Source)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:653)
> 	at org.jboss.system.ServiceController.register(ServiceController.java:356)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerRegistrationLifecycleCallback.install(ServiceControllerRegistrationLifecycleCallback.java:104)
> 	at sun.reflect.GeneratedMethodAccessor239.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 14:02:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 14:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-132) Track component
	updates
Message-ID: <16504899.1248890549157.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Track component updates
-----------------------

                 Key: JBJCA-132
                 URL: https://jira.jboss.org/jira/browse/JBJCA-132
             Project: JBoss JCA
          Issue Type: Task
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha3




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 14:26:29 2009
From: jira-events at lists.jboss.org (Juan Manuel Medina Apodaca (JIRA))
Date: Wed, 29 Jul 2009 14:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6442) Response truncated
 in the presence of special character
In-Reply-To: <31820059.1233348224581.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1992406868.1248891989328.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juan Manuel Medina Apodaca updated JBAS-6442:
---------------------------------------------

    Attachment: SpecialChar.war


Hi.

You were right. The problem appears also if you print the special character directly from a servlet. The attached war reproduces the problem this way. It has only one servlet which prints messages before and after the special character.

If you print a few messages, nothing is shown. It seems like one has to fill the buffer before printing the special character in order to get some result in the Web page.

> Response truncated in the presence of special character
> -------------------------------------------------------
>
>                 Key: JBAS-6442
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6442
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows XP, JDK 1.6.0_11
>            Reporter: Juan Manuel Medina Apodaca
>            Assignee: Remy Maucherat
>         Attachments: SpecialChar.war, SpecialCharacter.txt
>
>
> When a servlet puts a session attribute containing a collection of strings, one of the strings contains a special character (for example: ...) and this string is displayed in a JSP, the resulting page is truncated before the special character.
> For example, in a servlet:
> ArrayList optionList = new ArrayList();
> ...
> optionList.add("Any string 1");
> optionList.add("Any string 2");
> optionList.add("Any string 3");
> optionList.add("Any string 4");
> optionList.add("A string with ... character");
> optionList.add("Any string 6");
> optionList.add("Any string 7");
> optionList.add("Any string 8");
> ...
> request.getSession(false).setAttribute("myList", optionList);
> In the JSP:
> 			               <c:forEach var="currentOption" items="${myList}">
> 			                  ${currentOption}
> 			                </c:forEach>
> The resulting page gets truncated before the 5th line.
> In JBoss 4.0.0 the page shows complete, with a ? sign in the place of the special character.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 14:34:29 2009
From: jira-events at lists.jboss.org (Juan Manuel Medina Apodaca (JIRA))
Date: Wed, 29 Jul 2009 14:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6442) Response truncated
 in the presence of special character
In-Reply-To: <31820059.1233348224581.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <257127958.1248892469234.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juan Manuel Medina Apodaca updated JBAS-6442:
---------------------------------------------

    Attachment: screenshot-1.jpg


This is the result of the execution of the test case. As you can see, it can be viewed using the path:     /SpecialChar/TestServlet

> Response truncated in the presence of special character
> -------------------------------------------------------
>
>                 Key: JBAS-6442
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6442
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows XP, JDK 1.6.0_11
>            Reporter: Juan Manuel Medina Apodaca
>            Assignee: Remy Maucherat
>         Attachments: screenshot-1.jpg, SpecialChar.war, SpecialCharacter.txt
>
>
> When a servlet puts a session attribute containing a collection of strings, one of the strings contains a special character (for example: ...) and this string is displayed in a JSP, the resulting page is truncated before the special character.
> For example, in a servlet:
> ArrayList optionList = new ArrayList();
> ...
> optionList.add("Any string 1");
> optionList.add("Any string 2");
> optionList.add("Any string 3");
> optionList.add("Any string 4");
> optionList.add("A string with ... character");
> optionList.add("Any string 6");
> optionList.add("Any string 7");
> optionList.add("Any string 8");
> ...
> request.getSession(false).setAttribute("myList", optionList);
> In the JSP:
> 			               <c:forEach var="currentOption" items="${myList}">
> 			                  ${currentOption}
> 			                </c:forEach>
> The resulting page gets truncated before the 5th line.
> In JBoss 4.0.0 the page shows complete, with a ? sign in the place of the special character.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 15:04:41 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 15:04:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-145) IDFedLSInputResolver
 should be made default for schema resolution
Message-ID: <1323610313.1248894281013.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

IDFedLSInputResolver should be made default for schema resolution
-----------------------------------------------------------------

                 Key: JBID-145
                 URL: https://jira.jboss.org/jira/browse/JBID-145
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 15:06:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 15:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-145) IDFedLSInputResolver
 should be made default for schema resolution
In-Reply-To: <1323610313.1248894281013.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <72018498.1248894389244.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-145.
------------------------------

    Resolution: Done


Disable by setting the system property "org.jboss.identity.federation.jaxb.ls" to a non-null value.

> IDFedLSInputResolver should be made default for schema resolution
> -----------------------------------------------------------------
>
>                 Key: JBID-145
>                 URL: https://jira.jboss.org/jira/browse/JBID-145
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 15:30:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 15:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-146) JAXBUtil: Marshaller
 setProperty formatted output should be false
Message-ID: <697355791.1248895829220.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JAXBUtil: Marshaller setProperty formatted output should be false
-----------------------------------------------------------------

                 Key: JBID-146
                 URL: https://jira.jboss.org/jira/browse/JBID-146
             Project: JBoss Identity
          Issue Type: Bug
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana


It will add newlines etc that can invalidate signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 15:30:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 15:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-146) JAXBUtil: Marshaller
 setProperty formatted output should be false
In-Reply-To: <697355791.1248895829220.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1061429405.1248895829339.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-146:
-------------------------------

          Component/s: Identity-Federation
        Fix Version/s: IDFED-1.0.0.beta1
    Affects Version/s: IDFED-1.0.0.alpha4


> JAXBUtil: Marshaller setProperty formatted output should be false
> -----------------------------------------------------------------
>
>                 Key: JBID-146
>                 URL: https://jira.jboss.org/jira/browse/JBID-146
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> It will add newlines etc that can invalidate signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 15:33:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 15:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBID-146) JAXBUtil:
 Marshaller setProperty formatted output should be false
In-Reply-To: <697355791.1248895829220.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <856504146.1248896009223.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBID-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478129#action_12478129 ] 

Anil Saldhana commented on JBID-146:
------------------------------------

http://forums.sun.com/thread.jspa?threadID=5198619&start=15&tstart=0  has some details.

> JAXBUtil: Marshaller setProperty formatted output should be false
> -----------------------------------------------------------------
>
>                 Key: JBID-146
>                 URL: https://jira.jboss.org/jira/browse/JBID-146
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> It will add newlines etc that can invalidate signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 15:35:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 15:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-146) JAXBUtil: Marshaller
 setProperty formatted output should be false
In-Reply-To: <697355791.1248895829220.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2069703874.1248896129199.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-146.
------------------------------

    Resolution: Done


> JAXBUtil: Marshaller setProperty formatted output should be false
> -----------------------------------------------------------------
>
>                 Key: JBID-146
>                 URL: https://jira.jboss.org/jira/browse/JBID-146
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> It will add newlines etc that can invalidate signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 15:35:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 15:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-147) XML Signature
 CanonicalizationMethod should be EXCLUSIVE_WITH_COMMENTS
Message-ID: <2016474749.1248896129276.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

XML Signature CanonicalizationMethod should be EXCLUSIVE_WITH_COMMENTS
----------------------------------------------------------------------

                 Key: JBID-147
                 URL: https://jira.jboss.org/jira/browse/JBID-147
             Project: JBoss Identity
          Issue Type: Bug
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha4
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1


Some details are at http://forums.sun.com/thread.jspa?threadID=5198619&start=15&tstart=0


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 15:58:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Wed, 29 Jul 2009 15:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6918) "trackByTxn" always
 gets displayed as "false" in the output of the "listStatistics" operation
 for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1582834059.1248897509318.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene reassigned JBAS-6918:
-------------------------------------

    Assignee: Charles Crouch  (was: Jason T. Greene)


I just checked with Jesper. This is deprecated, so it should just be ignored in the stats output

> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Charles Crouch
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 16:06:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 29 Jul 2009 16:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6918) "trackByTxn"
 always gets displayed as "false" in the output of the "listStatistics"
 operation for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1482674605.1248897989350.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478140#action_12478140 ] 

Ian Springer commented on JBAS-6918:
------------------------------------

Just to clarify, it's deprecated for all types of datasources and connection factories, or just for XA datasources and connection factories?


> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Charles Crouch
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 16:08:29 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Wed, 29 Jul 2009 16:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6918) "trackByTxn"
 always gets displayed as "false" in the output of the "listStatistics"
 operation for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <535282217.1248898109316.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478142#action_12478142 ] 

Ondrej ?i?ka commented on JBAS-6918:
------------------------------------

And to clarify more, does the property "interleaving" have the same meaning as _negated_ track-conn... ?

> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Charles Crouch
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Wed Jul 29 16:30:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Wed, 29 Jul 2009 16:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6918) "trackByTxn" always
 gets displayed as "false" in the output of the "listStatistics" operation
 for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1376930371.1248899429323.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch reassigned JBAS-6918:
------------------------------------

    Assignee: Jason T. Greene  (was: Charles Crouch)


Back to Jason for more info

> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Jason T. Greene
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 16:56:51 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 29 Jul 2009 16:56:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6918) "trackByTxn" always
 gets displayed as "false" in the output of the "listStatistics" operation
 for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1471685896.1248901011105.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer reassigned JBAS-6918:
----------------------------------

    Assignee: Jesper Pedersen  (was: Jason T. Greene)


> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Jesper Pedersen
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 17:18:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Jul 2009 17:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1691) JBM2 cluster
 fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1395189469.1248902309302.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic reassigned JBMESSAGING-1691:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)


> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Clebert Suconic
>         Attachments: cluster-nodes-config-files.zip, Jbm2ClusterTest-NodeA.zip, Jbm2ClusterTest-NodeB.zip
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 17:44:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 17:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7133) Logging error at
	midnight
Message-ID: <1226095905.1248903869144.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Logging error at midnight
-------------------------

                 Key: JBAS-7133
                 URL: https://jira.jboss.org/jira/browse/JBAS-7133
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Logging
            Reporter: David Lloyd
            Assignee: David Lloyd
            Priority: Minor
             Fix For: JBossAS-6.0.0.Alpha1


At midnight, we get:

LogManager error of type WRITE_FAILURE: Error writing log message
java.io.IOException: Stream closed
	at sun.nio.cs.StreamEncoder.ensureOpen(StreamEncoder.java:26)
	at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:99)
	at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:116)
	at java.io.OutputStreamWriter.write(OutputStreamWriter.java:203)
	at java.io.Writer.write(Writer.java:140)
	at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:65)
	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:59)
	at org.jboss.logmanager.Logger.logRaw(Logger.java:849)
	at org.slf4j.impl.Slf4jLogger.log(Slf4jLogger.java:68)
	at org.apache.commons.logging.impl.SLF4JLocationAwareLog.debug(SLF4JLocationAwareLog.java:120)
	at com.arjuna.common.internal.util.logging.jakarta.JakartaRelevelingLogger.debug(JakartaRelevelingLogger.java:172)
	at com.arjuna.common.internal.util.logging.LogNoi18nImpl.debug(LogNoi18nImpl.java:419)
	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:727)
	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:412)

...because of an order-of-operations error in the base logmanager handler.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 18:02:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 18:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCL-110) BaseClassLoader
 create message is insanely verbose
Message-ID: <1986339421.1248904949163.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

BaseClassLoader create message is insanely verbose
--------------------------------------------------

                 Key: JBCL-110
                 URL: https://jira.jboss.org/jira/browse/JBCL-110
             Project: JBoss ClassLoader
          Issue Type: Bug
          Components: ClassLoader, ClassLoaderPolicy, VFS
            Reporter: David Lloyd


When the AS starts up, we get messages like this:

19:18:42,479 DEBUG [BaseClassLoader] Created BaseClassLoader at 430e468f{vfsfile:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/conf/jboss-service.xml} with policy VFSClassLoaderPolicy at 5e3a78ad{name=vfsfile:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/conf/jboss-service.xml domain=null roots=[MemoryContextHandler at 1355339311[path= context=vfsmemory://3j001-2h0izc-fxpb6lon-1-fxpb6ps5-7 real=vfsmemory://3j001-2h0izc-fxpb6lon-1-fxpb6ps5-7], DelegatingHandler at 828756248[path=jacorb.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/jacorb.jar], DelegatingHandler at 327325694[path=jbosscache-core.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/jbosscache-core.jar], DelegatingHandler at 1657319091[path=avalon-framework.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/avalon-framework.jar], DelegatingHandler at 1699060847[path=jcip-annotations.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/jcip-annotations.jar], DelegatingHandler at 1025601370[path=jbosscache-pojo.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/jbosscache-pojo.jar], DelegatingHandler at 1578474768[path=jgroups.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/jgroups.jar], DelegatingHandler at 1559934385[path=hibernate-jbosscache2.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/hibernate-jbosscache2.jar], DelegatingHandler at 1336846119[path=jbosssx-server.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbosssx-server.jar], DelegatingHandler at 357453361[path=jboss.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss.jar], DelegatingHandler at 1398807119[path=jmx-adaptor-plugin.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jmx-adaptor-plugin.jar], DelegatingHandler at 1247765324[path=jboss-jsr88.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-jsr88.jar], DelegatingHandler at 1013987513[path=jbossas-remoting.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossas-remoting.jar], DelegatingHandler at 1805392046[path=jboss-jmx-remoting.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-jmx-remoting.jar], DelegatingHandler at 1427668659[path=jboss-messaging-int.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-messaging-int.jar], DelegatingHandler at 992363882[path=jbossha.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossha.jar], DelegatingHandler at 1301762172[path=autonumber-plugin.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/autonumber-plugin.jar], DelegatingHandler at 153429168[path=hsqldb-plugin.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/hsqldb-plugin.jar], DelegatingHandler at 1703650176[path=scheduler-plugin.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/scheduler-plugin.jar], DelegatingHandler at 849042581[path=hsqldb.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/hsqldb.jar], DelegatingHandler at 1977308199[path=mail-plugin.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/mail-plugin.jar], DelegatingHandler at 309463268[path=properties-plugin.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/properties-plugin.jar], DelegatingHandler at 2091235889[path=jboss-srp.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-srp.jar], DelegatingHandler at 1684219621[path=scheduler-plugin-example.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/scheduler-plugin-example.jar], DelegatingHandler at 697219040[path=jboss-monitoring.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-monitoring.jar], DelegatingHandler at 1489627248[path=jboss-iiop.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-iiop.jar], DelegatingHandler at 800800410[path=jboss-iiop-client.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-iiop-client.jar], DelegatingHandler at 772475121[path=jboss-as-profileservice.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-as-profileservice.jar], DelegatingHandler at 1450712532[path=jboss-common-jdbc-wrapper.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-common-jdbc-wrapper.jar], DelegatingHandler at 1743680933[path=jboss-jca.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-jca.jar], DelegatingHandler at 1483593969[path=jbosscx-client.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbosscx-client.jar], DelegatingHandler at 331211666[path=jboss-management.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-management.jar], DelegatingHandler at 396857438[path=jboss-jsr77.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-jsr77.jar], DelegatingHandler at 2046236531[path=jboss-as-hibernate-int.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-as-hibernate-int.jar], DelegatingHandler at 1294253459[path=jbossjts.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossjts.jar], DelegatingHandler at 656024950[path=jcl-over-slf4j.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jcl-over-slf4j.jar], DelegatingHandler at 630290952[path=dtdparser.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/dtdparser.jar], DelegatingHandler at 1910683260[path=jboss-ejb3-proxy-spi.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-proxy-spi.jar], DelegatingHandler at 1530577229[path=jboss-ha-server-api.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ha-server-api.jar], DelegatingHandler at 1852364037[path=jboss-ejb3-common.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-common.jar], DelegatingHandler at 611939300[path=jboss-ejb3-ext-api-impl.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-ext-api-impl.jar], DelegatingHandler at 564629617[path=jboss-messaging.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-messaging.jar], DelegatingHandler at 2147220473[path=jboss-security-spi.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-security-spi.jar], DelegatingHandler at 2019285523[path=hibernate-jmx.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/hibernate-jmx.jar], DelegatingHandler at 1447711520[path=quartz.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/quartz.jar], DelegatingHandler at 697796130[path=jbossws-native-saaj.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossws-native-saaj.jar], DelegatingHandler at 451360643[path=servlet-api.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/servlet-api.jar], DelegatingHandler at 1106085697[path=jboss-ejb3-mc-int.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-mc-int.jar], DelegatingHandler at 1363861047[path=jbossjts-integration.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossjts-integration.jar], DelegatingHandler at 172168851[path=jboss-ejb3-metadata.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-metadata.jar], DelegatingHandler at 981406248[path=jboss-logging-log4j.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-logging-log4j.jar], DelegatingHandler at 1820401176[path=jbossts-common.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossts-common.jar], DelegatingHandler at 283046223[path=jboss-ejb3-deployers.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-deployers.jar], DelegatingHandler at 481591856[path=jboss-jpa-deployers.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-jpa-deployers.jar], DelegatingHandler at 248458249[path=log4j.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/log4j.jar], DelegatingHandler at 1129581175[path=jboss-ejb3-proxy-clustered.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-proxy-clustered.jar], DelegatingHandler at 1115368745[path=jboss-ejb3-timerservice-spi.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-timerservice-spi.jar], DelegatingHandler at 617742552[path=jboss-security-aspects.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-security-aspects.jar], DelegatingHandler at 1463121866[path=jboss-remoting.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-remoting.jar], DelegatingHandler at 2001443712[path=commons-collections.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/commons-collections.jar], DelegatingHandler at 80620976[path=jbossws-native-jaxws-ext.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossws-native-jaxws-ext.jar], DelegatingHandler at 2082046022[path=joesnmp.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/joesnmp.jar], DelegatingHandler at 1848947536[path=xnio-api.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/xnio-api.jar], DelegatingHandler at 1172865462[path=jboss-ha-client.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ha-client.jar], DelegatingHandler at 597424021[path=jsp-api.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jsp-api.jar], DelegatingHandler at 1419471222[path=jnpserver.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jnpserver.jar], DelegatingHandler at 656993631[path=jboss-ha-server-cache-jbc.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ha-server-cache-jbc.jar], DelegatingHandler at 1878526990[path=jboss-logging-jdk.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-logging-jdk.jar], DelegatingHandler at 98542736[path=jboss-ha-server-cache-spi.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ha-server-cache-spi.jar], DelegatingHandler at 497872115[path=jboss-ejb3-security.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-security.jar], DelegatingHandler at 1140348093[path=jboss-ejb3-endpoint.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-endpoint.jar], DelegatingHandler at 1686333223[path=jbossws-native-jaxws.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossws-native-jaxws.jar], DelegatingHandler at 1860789502[path=jbossxacml.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossxacml.jar], DelegatingHandler at 484808853[path=jboss-ejb3-transactions.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-transactions.jar], DelegatingHandler at 629435653[path=jaxen.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jaxen.jar], DelegatingHandler at 420574849[path=jboss-threads.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-threads.jar], DelegatingHandler at 1232804866[path=jbosssx.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbosssx.jar], DelegatingHandler at 829156606[path=jboss-negotiation.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-negotiation.jar], DelegatingHandler at 613691659[path=slf4j-api.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/slf4j-api.jar], DelegatingHandler at 2099239919[path=hibernate-core.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/hibernate-core.jar], DelegatingHandler at 916482070[path=jboss-current-invocation-aspects.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-current-invocation-aspects.jar], DelegatingHandler at 1561434206[path=antlr.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/antlr.jar], DelegatingHandler at 774533902[path=jboss-ejb3-core.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-core.jar], DelegatingHandler at 1692906447[path=jbossws-framework.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossws-framework.jar], DelegatingHandler at 667815626[path=jbossjts-jacorb.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossjts-jacorb.jar], DelegatingHandler at 1227686960[path=jboss-ejb3-interceptors.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-interceptors.jar], DelegatingHandler at 711856344[path=hibernate-annotations.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/hibernate-annotations.jar], DelegatingHandler at 538176171[path=jboss-remoting-aspects.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-remoting-aspects.jar], DelegatingHandler at 2073268480[path=jboss-ejb3-ext-api.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-ext-api.jar], DelegatingHandler at 353687138[path=jboss-transaction-aspects.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-transaction-aspects.jar], DelegatingHandler at 184993470[path=slf4j-jboss-logmanager.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/slf4j-jboss-logmanager.jar], DelegatingHandler at 1776413081[path=jboss-javaee.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-javaee.jar], DelegatingHandler at 1856991773[path=bsf.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/bsf.jar], DelegatingHandler at 1080886960[path=jboss-integration.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-integration.jar], DelegatingHandler at 902966747[path=hibernate-validator.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/hibernate-validator.jar], DelegatingHandler at 2042667127[path=jboss-metadata.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-metadata.jar], DelegatingHandler at 1432822547[path=bsh.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/bsh.jar], DelegatingHandler at 1714413618[path=jboss-serialization.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-serialization.jar], DelegatingHandler at 1361585927[path=hibernate-entitymanager.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/hibernate-entitymanager.jar], DelegatingHandler at 588932657[path=hibernate-commons-annotations.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/hibernate-commons-annotations.jar], DelegatingHandler at 439037176[path=ejb3-persistence.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ejb3-persistence.jar], DelegatingHandler at 144005940[path=jboss-jaspi-api.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-jaspi-api.jar], DelegatingHandler at 93763411[path=jboss-logmanager-log4j.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-logmanager-log4j.jar], DelegatingHandler at 1776135426[path=bcel.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/bcel.jar], DelegatingHandler at 1485411482[path=jbossws-native-jaxrpc.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossws-native-jaxrpc.jar], DelegatingHandler at 813381599[path=mail.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/mail.jar], DelegatingHandler at 1771121238[path=jbossws-common.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossws-common.jar], DelegatingHandler at 963815999[path=jboss-ejb3-cache.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-cache.jar], DelegatingHandler at 386345872[path=jbossws-spi.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossws-spi.jar], DelegatingHandler at 1472005823[path=jboss-ejb3-proxy-impl.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-proxy-impl.jar], DelegatingHandler at 990253721[path=el-api.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/el-api.jar], DelegatingHandler at 196024597[path=log4j-snmp-appender.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/log4j-snmp-appender.jar]]  delegates=null exported=[org.hibernate.loader.collection, , org.omg.CosNaming.NamingContextPackage, org.jboss.deployers.spi.management.deploy, org.jboss.remoting.transporter, org.jboss.cache.pojo.annotation, org.jboss.ejb3.proxy.clustered.objectfactory.session.stateful, com.arjuna.ats.internal.jta.transaction.jts.subordinate, com.arjuna.ats.internal.jts.interposition.resources.osi, com.arjuna.ats.txoj.semaphore, org.jboss.wsf.common.injection.finders, org.jboss.varia.property, org.jboss.jms.server.messagecounter, com.arjuna.common.util.logging, com.arjuna.common.util.propertyservice, com.arjuna.ats.internal.jts.orbspecific.interposition.resources.osi, org.jacorb.transport, org.jboss.remoting.samples.transporter.proxy, org.jboss.remoting.invocation, META-INF.maven.org.jboss.jbossas.jboss-as-hibernate-int, javax.persistence, org.hibernate.engine.loading, org.jboss.cache.annotations, org.jboss.security.xacml.sunxacml.combine, org.jboss.jms.client.remoting, org.jboss.remoting.samples.transporter.serialization.server, com.arjuna.ats.internal.txoj.recovery, org.jboss.cache.commands.legacy.write, javax.xml.registry.infomodel, org.omg.PortableServer.CurrentPackage, org.jboss.resource.adapter.jdbc.remote, com.arjuna.orbportability.orb, org.jboss.logging.log4j, org.jboss.resource.spi.timer, org.jboss.ha.cachemanager, META-INF.maven.org.jboss.logmanager.jboss-logmanager-log4j, org.jboss.web.tomcat.service.session.distributedcache.spi, org.jboss.wsf.test, org.jboss.ejb3.cluster.metadata, org.jgroups.tests.stack, org.jboss.metadata.annotation.creator.client, org.hibernate.cache.jbc2.query, org.jboss.resource.statistic.formatter, org.omg.CosEventChannelAdmin, com.arjuna.ats.internal.jta.transaction.arjunacore, org.jboss.security.mapping.providers.principal, org.jboss.hibernate.deployers.metadata, com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators, org.jboss.wsf.common.management, org.jboss.resource.metadata, javax.enterprise.deploy.spi, org.apache.log4j.lf5, org.jboss.remoting.detection.jndi, org.jboss.security.integration, com.arjuna.common.internal.util.logging.simpleLog, org.jboss.jms.server.remoting, org.jboss.ejb3.metadata, org.hibernate.cache.access, META-INF.maven.org.jboss.cluster.jboss-ha-server-api, org.jboss.remoting.samples.transporter.basic, org.apache.bsf.util, org.hibernate.intercept.cglib, org.jboss.remoting.transport.sslrmi, org.jgroups.mux, org.hibernate.proxy, org.jboss.cache.commands.tx, org.apache.bcel.verifier.exc, org.jboss.remoting.stream, com.arjuna.orbportability.internal, org.apache.log4j.varia, org.hibernate.cache, org.jboss.security.auth.container.config, org.jboss.jmx.adaptor.rmi, javax.security.auth.message.module, org.hibernate.usertype, org.jboss.management.j2ee.statistics, org.jboss.remoting, org.jboss.serial.util, org.jacorb.security.sas, org.jboss.security.acl.config, org.omg.Messaging, org.jboss.resource.adapter.jdbc.vendor, com.arjuna.ArjunaOTS, org.jboss.resource.adapter.jdbc, META-INF.maven.org.jboss.ws.native.jbossws-native-saaj, org.hibernate.ejb.event, org.jboss.metadata.validation.chain.ejb.jboss, com.arjuna.ats.internal.jts.utils, com.arjuna.ats.jta.utils, org.jboss.monitor.alerts, javax.servlet, org.hibernate.annotations, com.arjuna.ats.internal.jts.orbspecific.interposition.resources.arjuna, org.omg.GIOP, org.jboss.jms.wireformat, antlr.debug.misc, com.arjuna.ats.internal.arjuna.objectstore.jdbc, org.hibernate.hql.ast.exec, org.jboss.security.xacml.jaxb, org.jboss.ejb3.deployers, org.jboss.profileservice.cluster.repository, org.jboss.metadata.process.processor, org.jboss.wsf.spi.util, org.hibernate.context, org.jboss.remoting.samples.detection.multicast, org.jboss.xnio.management, org.jboss.jmx.connector.invoker, javax.enterprise.deploy.model, org.jboss.web.tomcat.service.session.distributedcache.impl.jbc, xmdesc, org.jboss.ejb3.interceptors.container, org.jboss.remoting.transport.web, META-INF.maven.org.hibernate.hibernate-jbosscache2, javax.enterprise.deploy.shared, org.hibernate.id.enhanced, org.jboss.metadata.common.jboss, org.hibernate.cache.jbc2.builder, org.jboss.ejb3.enc, org.jboss.ejb3.proxy.factory, org.jboss.cache.notifications.annotation, org.jboss.remoting.samples.callback.statistics, org.jboss.proxy.ejb.handle, com.arjuna.ats.jta.xa, org.jboss.ejb3.proxy.clustered.factory.session.stateful, org.jboss.metadata.serviceref, javax.mail.event, org.jboss.ejb3.proxy.impl.objectfactory.session.stateless, org.apache.bsf.engines.xslt, org.jaxen.pattern, org.jboss.ha.client.loadbalance, org.apache.log4j.lf5.viewer, org.jboss.ejb.plugins.cmp.jdbc, org.jboss.ejb3.proxy.impl.objectstore, org.jboss.metadata.annotation.finder, org.jboss.jms.server.security, org.jboss.aspects.currentinvocation, org.jboss.wsf.framework.serviceref, org.jboss.web.tomcat.service.session.distributedcache.impl, org.jboss.ejb3.dependency, org.jboss.iiop.jacorb, com.arjuna.ats.jbossatx.jta, org.omg.CORBA.TypeCodePackage, org.omg.PortableInterceptor, org.apache.bcel.generic, org.slf4j.helpers, org.quartz.plugins.xml, com.arjuna.ats.txoj.lockstore, META-INF.maven.org.jboss.ejb3.jboss-ejb3-timerservice-spi, com.sun.mail.handlers, org.jboss.remoting.serialization.impl.java, org.jboss.profileservice.management.mbean, org.jboss.metadata.jpa.spec, META-INF.maven.org.jboss.ejb3.jboss-ejb3-mc-int, org.jboss.cache.pojo.memory, org.jboss.ejb3.endpoint, org.hibernate.intercept.javassist, com.arjuna.orbportability.internal.orbspecific.orb.implementations, org.jboss.injection.lang.reflect, META-INF.maven.org.jboss.logging.jboss-logging-log4j, com.arjuna.ats.jbossatx.jts, org.jboss.ejb3.proxy.impl.objectfactory, org.jacorb.naming, org.jboss.ejb3.protocol.jarjar, org.jboss.remoting.transport.servlet, org.omg.CORBA_2_3, com.arjuna.ats.internal.jta.xa, org.jboss.ha.client.loadbalance.aop, org.omg.CORBA_2_5, org.hibernate.stat, javax.xml.ws, org.jboss.invocation.iiop, org.jboss.ejb3.proxy.impl.invocation, com.arjuna.ats.tsmx.mbeans, org.jboss.deployers.spi.management, org.jboss.varia.autonumber, org.quartz.simpl, org.jacorb.notification.servant, org.jboss.cache.factories.annotations, org.omg.PortableServer, org.jboss.security.plugins.acl, org.jboss.deployment.services, org.jboss.profileservice.management, org.jacorb.imr.RegistrationPackage, javax.xml.rpc.handler.soap, org.quartz.jobs, com.arjuna.orbportability.utils, org.omg.IOP.CodecFactoryPackage, org.jboss.ws.tools.io, org.hibernate.impl, com.arjuna.ats.internal.arjuna.gandiva.nameservice, org.jboss.wsf.common.reflection, org.hibernate.event.def, org.jboss.remoting.samples.multiplex, org.jgroups.annotations, org.hibernate.persister, org.hibernate.ejb.transaction, org.hibernate.validator.resources, org.omg.CosEventComm, org.jboss.remoting.samples.transporter.complex.server, org.jboss.remoting.marshal.serializable, org.jboss.ejb3.proxy.clustered.handler.session.stateful, org.jboss.security.mapping.providers, org.jboss.wsf.framework.management.recording, org.jboss.messaging.core.impl.jchannelfactory, org.jnp.interfaces, org.jboss.verifier, javax.xml.rpc, org.jboss.ejb3.interceptors.currentinvocation, org.opennms.protocols.snmp.asn1, org.hibernate.tool.instrument.cglib, org.jboss.profileservice.spi.metadata, org.jboss.client, org.hibernate.annotations.common.reflection.java, bsh.util.lib, com.arjuna.ats.internal.jts.orbspecific.interposition.coordinator, org.jboss.remoting.samples.transporter.multiple.client, org.jboss.security.xacml.interfaces, org.jboss.ha.hasessionstate.server, org.jboss.iiop.test, org.quartz.core, org.jboss.ejb.plugins.cmp.jdbc2.schema, org.jboss.ejb3.interceptors.proxy, META-INF.maven.org.jboss.jpa.jboss-jpa-deployers, com.arjuna.ats.internal.arjuna.template, com.arjuna.ats.txoj.logging, org.jboss.metadata.ejb.spec, org.hibernate.type, com.arjuna.ats.arjuna.gandiva.inventory, org.omg.IOP.CodecPackage, javax.xml.ws.http, org.jboss.verifier.strategy, com.arjuna.ats.jbossatx.logging, org.omg.PortableServer.portable, org.jgroups.auth, org.jgroups.conf, org.jboss.remoting.samples.transporter.custom.server, org.apache.bsf.util.event.adapters, org.jacorb.orb.policies, org.jboss.cache.config.parsing.element, org.jboss.cache.loader.jdbm, org.apache.commons.collections.set, org.apache.log4j.lf5.viewer.images, org.hibernate.loader, org.jboss.jms.delegate, org.hibernate.engine, org.quartz.spi, com.arjuna.ats.jts.common, META-INF.maven.org.jboss.ws.jbossws-common, org.jboss.security.propertyeditor, org.jboss.ha.framework.server.util, com.arjuna.orbportability.exceptions, org.jboss.mail, org.jboss.remoting.detection.util, org.jboss.ws.core.utils, org.jboss.ejb, com.arjuna.ats.jts.tx, org.jboss.wsf.spi.metadata.j2ee.serviceref, com.arjuna.ats.jdbc, org.jboss.ha.jndi.spi, com.arjuna.orbportability.internal.common, com.arjuna.orbportability.logging, org.jboss.serial.objectmetamodel, org.hsqldb.jdbc, META-INF.maven.org.hibernate.hibernate-core, com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca, org.jboss.cache.cluster, javax.mail.util, org.apache.log4j.nt, org.omg.PortableServer.ServantLocatorPackage, org.jboss.security.srp, com.arjuna.ats.internal.txoj.semaphore, com.arjuna.common.internal.util.propertyservice.plugins.io, org.jboss.security.xacml.locators, com.arjuna.ats.internal.jbossatx.jta.jca, org.hibernate.tuple, org.jboss.remoting.transport.rmi, org.hibernate.annotations.common.reflection, bsh.reflect, org.hibernate.classic, org.jboss.web, org.hibernate.ejb.connection, org.jboss.security.xacml.util, org.jgroups.tests, org.jboss.security.ssl, org.jboss.ejb3.mdb, javax.transaction.xa, org.apache.bsf.engines.netrexx, org.hsqldb, javax.security.auth.message.config, org.hibernate.jdbc.util, com.arjuna.ats.jta.common, org.omg.CosTypedNotifyComm, META-INF.maven.org.jboss.ejb3.jboss-ejb3-endpoint, com.wutka.dtd, org.jboss.jms.server.connectormanager, com.arjuna.ats.jts.utils, org.jboss.metadata.process.processor.ejb.jboss, org.jboss.cache.pojo.notification.event, org.jboss.cache.loader.tcp, org.omg.stub.javax.ejb, org.jboss.jpa.tx, org.hibernate.loader.entity, org.jboss.remoting.samples.oneway, org.jacorb.orb.dii, org.jboss.messaging.core.impl.clusterconnection, com.arjuna.ats.internal.jta.utils.jts, org.jboss.wsf.spi.deployment, org.jboss.ejb3.interceptors.direct, antlr.collections.impl, org.hibernate, org.apache.log4j.or, org.jboss.cache.factories, javax.xml.rpc.soap, org.hibernate.bytecode.util, org.hsqldb.sample, org.jboss.ha.jndi, com.arjuna.ats.internal.tsmx.agent.exceptions, org.hsqldb.lib, org.jboss.ejb3.metamodel, com.arjuna.ats.txoj.exceptions, org.omg.CosTypedNotifyChannelAdmin, com.arjuna.ats.jts.exceptions, org.omg.CosNotifyFilter, javax.management.remote.rmi, org.apache.log4j.or.jms, javax.interceptor, META-INF.maven.org.jboss.ws.native.jbossws-native-jaxws-ext, org.jboss.wsf.spi.tools.ant, security, org.jboss.resource.timer, com.arjuna.ats.tsmx.agent.exceptions, org.apache.avalon.framework.activity, com.arjuna.ats.jta.transaction, org.jacorb.orb.giop, org.jboss.ejb3.metadata.plugins.loader, org.jboss.deployment.vfs, com.arjuna.ats.internal.jta.recovery.arjunacore, org.jaxen, com.arjuna.ats.internal.jts.lifecycle, com.arjuna.ats.jta.resources, org.jboss.wsf.common.logging, org.jboss.ejb3.aop, META-INF.maven.org.jboss.ejb3.jboss-ejb3-security, org.omg.DynamicAny, com.arjuna.ats.arjuna.utils, org.jboss.jms.client.delegate, bsh.commands, org.jacorb.orb.iiop, com.arjuna.ats.tsmx.agent, org.jboss.security.xacml.sunxacml.support, org.jboss.serial.finalcontainers, com.arjuna.ats.internal.txoj.lockstore, org.jboss.resource.security, com.arjuna.ats.jts.recovery, org.jboss.messaging.core.impl.tx, org.jgroups.debug, org.jboss.cache.eviction, org.jboss.resource.connectionmanager, javax.xml.ws.addressing.soap, org.jboss.deployment.dependency, com.arjuna.ats.internal.jdbc.drivers, org.quartz.impl.calendar, org.jboss.security.identity.fed, com.arjuna.ats.internal.jts.orbspecific.recovery.recoverycoordinators, org.jboss.ejb3.kernel, META-INF.maven.org.jboss.ejb3.jboss-ejb3-proxy-clustered, org.jboss.wsf.framework, com.arjuna.ats.arjuna.coordinator, org.jboss.invocation, javax.servlet.http, org.jboss.metadata.validation, com.arjuna.common.internal.util.licence.utils, org.jacorb.util, org.hibernate.bytecode, javax.jws, org.jboss.jms.exception, org.jboss.security.mapping, org.jboss.ejb3.interceptors.lang, org.apache.log4j.spi, org.jboss.ejb3.common.resolvers.spi, org.jboss.logmanager.log4j.handlers, org.jboss.ejb3.core.resolvers, com.arjuna.ats.jts.thread, org.jboss.logmanager.log4j, com.arjuna.ats.arjuna.gandiva.nameservice, org.jboss.ejb3.naming, org.jboss.security.xacml.sunxacml.ctx, org.jboss.messaging.core.impl, org.jboss.remoting.samples.transporter.clustered.server, org.jboss.jpa.resolvers, META-INF.maven.org.jboss.slf4j.slf4j-jboss-logmanager, org.hsqldb.util.sqltool, org.jboss.hibernate.deployers, org.jboss.ejb.plugins.local, org.jacorb.events, org.jboss.cache.pojo, org.jboss.monitor, org.jboss.cache.pojo.notification, org.jboss.remoting.samples.transporter.proxy.client, org.hibernate.cache.entry, org.jboss.threads, org.quartz, org.hibernate.hql, org.jgroups.protocols.pbcast, org.jboss.security.auth.spi, org.hibernate.tuple.component, org.hibernate.transform, com.arjuna.common.util, com.arjuna.orbportability.internal.orbspecific.jacorb.orb.implementations, org.jboss.ejb3.cache.persistence, org.jboss.invocation.pooled.server, org.jboss.security.identitytrust.modules, org.jboss.metadata.common.spi, com.arjuna.ats.internal.jta.utils, org.jboss.cache.pojo.util, com.arjuna.ats.internal.jts.orbspecific.recovery, org.jboss.cache.notifications.event, org.jboss.security.authorization.modules, org.jboss.verifier.event, org.jboss.iiop.rmi.marshal, org.jboss.ejb3.proxy.clustered.registry, org.apache.log4j.jdbc, org.jgroups.tests.perf.transports, com.arjuna.ats.internal.jta.recovery.jts, org.jboss.ejb3.common.resolvers.plugins, org.apache.bcel.util, org.jboss.annotation.javaee, com.arjuna.ats.internal.jta.resources.errorhandlers, org.jboss.ejb3.proxy.clustered.familyname, org.jboss.ejb3.metadata.annotation, org.hibernate.sql, org.omg.TimeBase, org.jboss.messaging.util, org.jboss.ejb.plugins.cmp.jdbc.metadata, org.jacorb.notification.conf, com.arjuna.common.util.propertyservice.propertycontainer, org.hsqldb.persist, org.jboss.invocation.http.server, org.jboss.wsf.spi.metadata.injection, org.jboss.remoting.transport.sslsocket, org.jboss.ejb3.interceptors.aop, org.hibernate.lob, com.arjuna.ats.arjuna.state, org.jboss.ejb3.security.helpers, org.jboss.ejb3.proxy.impl.objectfactory.session, org.jboss.wsf.spi.management, org.jboss.remoting.detection.multicast, org.jboss.security.authorization.modules.web, antlr.build, org.hibernate.persister.entity, org.jboss.classloading.spi, org.jboss.metadata.rar.jboss, org.jboss.jpa.injection, org.apache.bsf.engines.jacl, org.jboss.mx.remoting.event, org.jboss.wsf.common.concurrent, META-INF.maven.org.jboss.ejb3.jboss-ejb3-ext-api, org.jboss.jca.spi, org.jboss.remoting.samples.bisocket, com.arjuna.orbportability.internal.orbspecific.oa.implementations, org.omg.CORBA.InterfaceDefPackage, META-INF.maven.org.jboss.jbossas.jboss-as-management, org.apache.log4j.lf5.viewer.configure, org.jboss.logging.jdk.handlers, org.jboss.ejb3.security.embedded.plugins, org.jboss.ejb3.common.registrar.spi, org.jboss.naming.java, org.jboss.crypto.digest, org.apache.avalon.framework.thread, org.jboss.security.xacml.sunxacml, org.jboss.remoting.samples.transporter.complex, org.jacorb.ir, META-INF.maven.org.jboss.ejb3.jboss-ejb3-ext-api-impl, org.jgroups.demos.applets, com.arjuna.ats.arjuna.thread, org.apache.commons.collections.map, javax.xml.rpc.holders, org.jboss.jms.server.plugin.contract, org.jboss.ejb3.interceptors.registry, org.omg.CosPropertyService, org.jboss.tm.usertx.client, org.jboss.security.negotiation.ntlm.encoding, org.hibernate.cfg.search, com.arjuna.ats.txoj, org.jboss.remoting.transport.bisocket, org.jboss.resource.binding.remote, org.jboss.ejb3.injection, com.arjuna.ats.txoj.common, org.jboss.wsf.spi.serviceref, javax.security.jacc, org.jacorb.orb.listener, org.jboss.ejb3.proxy.impl.factory.session, org.jboss.wsf.common.utils, META-INF.maven.org.jboss.ws.native.jbossws-native-jaxrpc, org.jboss.jms.server.bridge, org.jgroups, com.arjuna.ats.internal.arjuna, javax.enterprise.deploy.spi.exceptions, org.omg.SecurityAdmin, org.quartz.xml, org.jboss.management.j2ee, org.jboss.deployment.spi.configurations, bsh.servlet, org.jboss.aspects.tx, org.apache.commons.collections.iterators, org.jboss.serial.io, org.jboss.cache.util, org.jacorb.dds, META-INF.maven.org.jboss.jbossas.jboss-as-profileservice, com.arjuna.orbportability.internal.orbspecific.jacorb.oa.implementations, com.arjuna.orbportability.orb.core, org.hibernate.cfg.annotations.reflection, org.hibernate.id, com.arjuna.ats.internal.jts.interposition.resources.strict, org.jboss.ejb3.common.thread, org.jboss.config, com.arjuna.common, org.jboss.jpa.util, org.jboss.deployment, org.jacorb.poa.gui.poa, org.apache.avalon.framework.logger, javax.ejb.spi, org.jboss.cache.util.concurrent, org.jboss.ejb3.common.metadata, bsh.collection, org.jboss.metamodel.descriptor, com.arjuna.ats.internal.jta.transaction.jts.jca, org.jboss.ejb3.proxy.impl.factory.session.service, org.jboss.profileservice.management.upload, org.jboss.invocation.local, META-INF.maven.org.slf4j.slf4j-api, org.jaxen.function, META-INF.maven.org.jboss.cluster.jboss-ha-client, org.jboss.logging.appender, org.jboss.security.microcontainer.beans.metadata, org.jboss.remoting.samples.multiplex.invoker, org.jboss.cache.buddyreplication, com.arjuna.ats.arjuna.objectstore.jdbc, org.jaxen.javabean, org.jboss.ejb3.tx.container, org.jboss.lang.ref, org.hsqldb.resources, org.jboss.security.xacml.sunxacml.finder.impl, org.jboss.ejb3.common.spi, org.jboss.metadata.process.chain.ejb.jboss, com.arjuna.ats.internal.jta.resources.jts.orbspecific, org.jboss.security.xacml.sunxacml.support.finder, org.jboss.jms.server.container, org.jboss.profileservice.management.templates, org.apache.bsf.util.cf, org.quartz.utils, org.hibernate.validator.event, org.jboss.ha.framework.test, javax.security.auth.message.callback, org.jboss.ejb3.common.lang, org.hsqldb.lib.java, org.jacorb.security.ssl.sun_jsse, org.jboss.cache.lock, org.jboss.iiop.naming, org.jboss.cache.pojo.notification.annotation, com.arjuna.ats.internal.jts.interposition, org.jboss.cache.loader.s3, org.jboss.security.xacml.bridge, org.jboss.remoting.samples.chat, org.jacorb.orb.etf, org.jnp.server, com.arjuna.ats.internal.jbossatx.jts, org.hsqldb.scriptio, org.jboss.metadata.client.spec, org.w3c.dom, org.jboss.logging.filter, org.jaxen.function.ext, com.arjuna.ats.tsmx.common, javax.management.remote, org.omg.dds, com.arjuna.ats.internal.jbossatx.jta, org.jboss.ejb3.security.annotation, org.jacorb.notification.interfaces, org.jnp.interfaces.java, bsh, org.jboss.ejb3.entity.hibernate, org.apache.log4j.lf5.util, org.jboss.metadata.annotation.creator.ws, org.jaxen.saxpath.helpers, org.quartz.plugins.management, org.jboss.remoting.samples.transporter.proxy.server, javax.jms, org.omg.CORBA, antlr.actions.python, org.jboss.ejb3.util, org.hibernate.loader.custom, stylesheets, javax.jws.soap, org.jnp.client, org.jboss.profileservice.management.upload.remoting, org.hibernate.engine.query.sql, org.jboss.ejb3.common.string, org.jboss.metadata.validation.validator.ejb.jboss, org.jboss.ejb3.metadata.spi.signature, org.jboss.ejb3.javaee, javax.resource.spi, org.hibernate.persister.collection, org.hibernate.hql.ast.tree, org.jboss.remoting.samples.simple, org.jboss.remoting.serialization, org.omg.CosNotifyChannelAdminAck, org.apache.avalon.framework.service, org.jboss.profileservice.management.matchers, org.jaxen.expr.iter, org.jboss.ejb3.proxy.impl.remoting, org.jboss.remoting.transport.servlet.web, org.jacorb.notification.engine, org.jboss.ha.singleton.examples, org.jacorb.transport.iiop, com.arjuna.ats.internal.jts.orbspecific.interposition.resources.restricted, org.jboss.ejb3.proxy.clustered.objectstore, org.jboss.remoting.samples.chat.utility, org.jboss.ejb3.timerservice.spi, org.jboss.jms.client.plugin, org.jboss.remoting.transport.sslservlet, com.arjuna.ats.internal.jts.resources, org.jboss.ejb3.proxy, org.jboss.security.plugins.audit, org.hibernate.hql.antlr, com.arjuna.ats.internal.jts.recovery.contact, org.jboss.security.identitytrust, org.jboss.ejb3.interceptors.annotation, org.jboss.deployment.spi.status, org.jacorb.transaction, org.jboss.cache.transaction, org.hibernate.proxy.pojo.javassist, org.jboss.remoting.loading, com.arjuna.ats.jts.extensions, javax.resource.spi.work, org.hibernate.cache.jbc2, com.arjuna.ats.jts.orbspecific.jacorb.interceptors.context, org.jboss.logging.jdk, org.omg.SSLIOP, com.arjuna.common.util.exceptions, org.jboss.security.jndi, org.apache.commons.collections.bidimap, META-INF.maven.org.jboss.aspects.jboss-remoting-aspects, org.jboss.ejb.plugins.lock, org.apache.bcel.verifier.structurals, org.jboss.remoting.samples.transporter.multiple, org.jboss.aspects.remoting.interceptors.invoker, org.jacorb.orb.portableInterceptor, org.quartz.helpers, org.jboss.varia.scheduler.example, com.arjuna.ats.jdbc.common, org.jboss.mx.remoting.provider.iiop, org.jboss.crypto, org.apache.bsf, org.jboss.security.identity, org.quartz.utils.weblogic, javax.servlet.jsp.tagext, org.jacorb.util.tracing.TracingServicePackage, org.hibernate.jmx, com.arjuna.ats.jbossatx, org.jboss.resource.work, javax.enterprise.deploy.spi.status, org.jboss.security.identitytrust.config, com.arjuna.ats.internal.jts.orbspecific.interposition.resources, org.jboss.metadata.validation.validator, org.hibernate.hql.ast, org.jboss.cache.pojo.interceptors, antlr, org.jacorb.poa.except, com.arjuna.ats.internal.txoj, org.jboss.resource.statistic, org.jboss.naming, org.jacorb.util.tracing, org.jboss.jms.server.connectionfactory, org.jboss.remoting.detection, org.hibernate.proxy.map, org.jboss.metadata.validation.chain, org.apache.commons.collections.buffer, org.jboss.wsf.spi.binding, org.jboss.wsf.spi.invocation, org.jboss.remoting.security, org.hibernate.annotations.common.util, javax.xml.registry, org.jboss.jpa.remote, org.jboss.metadata.javaee.jboss, org.jaxen.jdom, org.jboss.messaging.core.contract, org.jacorb.poa, org.jboss.ejb3.common.registrar.plugin.mc, org.jacorb.notification, org.jboss.messaging.util.prioritylinkedlist, org.apache.bsf.engines.javascript, antlr.preprocessor, com.arjuna.orbportability, com.arjuna.orbportability.common, org.jboss.wsf.framework.http, org.jboss.security.integration.password, org.jboss.ejb.plugins.jms, org.jboss.security.jce, org.quartz.ee.jmx.jboss.doc-files, javax.xml.rpc.server, org.jboss.ejb3.proxy.clustered.factory.session.stateless, com.sun.mail.smtp, org.omg.PortableInterceptor.ORBInitInfoPackage, org.jboss.cache.commands.remote, org.jboss.metadata.web.jboss, META-INF.maven.org.jboss.jbossas.jboss-as-messaging, org.jboss.remoting.transport.multiplex, org.jboss.executor, org.quartz.jobs.ee.mail, org.omg.CosConcurrencyControl, org.jboss.wsf.common, org.apache.log4j.or.sax, org.hibernate.cache.jbc2.util, org.jboss.cache.jmx, com.arjuna.orbportability.internal.utils, org.jaxen.util, org.jboss.remoting.samples.http, org.jacorb.notification.lifecycle, org.jboss.aspects.security, org.jboss.security.acl, org.omg.CORBA_2_3.portable, com.arjuna.common.util.concurrency, org.hibernate.cache.jbc2.entity, org.hibernate.engine.transaction, org.jboss.cache.config, org.hibernate.bytecode.cglib, org.jboss.jms.server.destination, org.jboss.util.stream, javax.enterprise.deploy.shared.factories, org.omg.DynamicAny.DynAnyFactoryPackage, org.jboss.ejb3.common.proxy.spi, org.jgroups.demos, org.jboss.ejb3.annotation, org.jboss.corba, org.jboss.cache.pojo.eviction, org.hibernate.loader.criteria, org.jboss.metadata.merge, org.jboss.logging.layout, org.jboss.ejb3.proxy.clustered.objectfactory.session.stateless, org.jboss.ejb3.proxy.clustered.jndiregistrar, com.arjuna.ats.internal.tsmx.mbeans, org.hibernate.annotations.common, org.jboss.remoting.ident, org.jboss.invocation.unified.interfaces, org.jboss.security.plugins.authorization, org.jboss.ejb.deployers, META-INF.maven.org.jboss.ejb3.jboss-ejb3-proxy-spi, org.hsqldb.util, org.jboss.hibernate, META-INF.maven.org.jboss.ejb3.jboss-ejb3-proxy-impl, META-INF.maven.org.slf4j.jcl-over-slf4j, org.jgroups.demos.wb, org.jboss.ejb3.metadata.jpa.spec, org.apache.avalon.framework.parameters, org.apache.avalon.framework.context, org.jboss.ha.framework.server.spi, org.jboss.ejb3.interceptor, org.jboss.jms.server.endpoint.advised, javax.servlet.jsp, org.jboss.mx.remoting, org.jboss.security.factories, org.jboss.resource.connectionmanager.xa, org.jboss.verifier.factory, org.jboss.ha.hasessionstate.interfaces, org.jboss.aspects.remoting.interceptors.marshall, org.hibernate.engine.query, META-INF.maven.org.jboss.ejb3.jboss-ejb3-cache, org.apache.commons.logging, org.jboss.deployment.security, org.jboss.jpa.javaee, META-INF.maven.org.jboss.jbossas.jboss-as-jmx-remoting, org.jboss.iiop.rmi.marshal.strategy, org.jboss.cache.invalidation.triggers, org.jboss.ejb3.endpoint.reflect, com.arjuna.ats.internal.arjuna.objectstore, org.omg.PortableServer.POAManagerPackage, org.jboss.tm, javax.resource.cci, org.jboss.jms.server, org.jboss.security.auth, org.jboss.management.j2ee.deployers, org.jacorb.notification.filter.impl, org.jboss.security.srp.jaas, com.arjuna.common.internal.util.propertyservice, javax.xml.ws.spi, org.jboss.naming.interceptors, org.jboss.metadata.annotation.creator.ejb.jboss, org.jboss.security.xacml.sunxacml.cond, org.jboss.security, com.arjuna.orbportability.recovery, org.jacorb.notification.filter.etcl, org.jboss.security.auth.message.config, org.apache.commons.collections.functors, META-INF.maven.org.jboss.jbossas.jboss-as-cluster, META-INF.maven.org.jboss.cluster.jboss-ha-server-cache-jbc, org.jboss.ejb3.proxy.clustered.invocation, org.jboss.ejb3.proxy.impl.objectfactory.session.stateful, org.hibernate.mapping, org.apache.avalon.framework, org.jboss.metadata.process, org.jboss.jms.server.endpoint, META-INF.services, org.quartz.impl, org.jboss.security.negotiation.common, com.arjuna.ats.internal.jts.orbspecific.interposition.resources.strict, org.jboss.ejb3.proxy.impl.handler.session, org.jgroups.jmx.protocols, org.hibernate.validator.interpolator, META-INF.maven.org.jboss.ws.jbossws-framework, org.jboss.ejb3.security, org.jboss.security.auth.login, com.arjuna.ats.jts.logging, org.apache.bsf.util.type, org.apache.commons.collections.collection, org.jboss.jms.client.state, org.jboss.remoting.samples.transporter.multiple.server, com.arjuna.ats.internal.jta.resources.arjunacore, org.jboss.remoting.samples.config.factories, org.jboss.ejb3.common.proxy.plugins.async, org.hibernate.ejb.instrument, org.apache.log4j.xml, org.jboss.remoting.samples.transporter.serialization, org.hibernate.action, org.jboss.resource, org.jboss.wsf.spi.tools, org.jboss.deployment.spi.beans, org.jboss.remoting.samples.transporter.clustered.client, com.arjuna.ats.internal.jts.recovery.recoverycoordinators, org.jboss.ejb3, org.jboss.metadata.annotation.creator, org.jboss.ha.framework.server.deployers, org.apache.bsf.engines.jython, org.jboss.wsf.framework.invocation, org.quartz.jobs.ee.jmx, org.jboss.invocation.jrmp.server, org.jgroups.util, org.jboss.wsf.spi.annotation, org.jboss.ejb3.connectionmanager, org.hibernate.dialect, com.arjuna.ats.internal.jta.resources.jts, org.jboss.ejb3.jms, org.jboss.invocation.unified.marshall, org.jacorb.poa.util, org.jboss.messaging.core.jmx, META-INF.maven.org.jboss.jbossas.jboss-as-jbossas-remoting, org.jboss.ejb3.common.classloader, org.jboss.wsf.spi.deployment.integration, javax.mail, org.jboss.jpa.resolvers.strategy, org.hibernate.bytecode.javassist, org.apache.log4j.helpers, META-INF.maven.org.jboss.metadata.jboss-metadata, com.arjuna.ats.jta.recovery, org.jboss.security.xacml.core.ext, org.jboss.proxy.generic, org.jboss.metadata.lang, org.jacorb.orb.dynany, org.omg.CosTypedEventChannelAdmin, com.arjuna.ats.arjuna, org.slf4j.impl, com.arjuna.ats.internal.tsmx.agent.implementations.ri, org.hsqldb.index, org.jboss.persistence, org.hibernate.connection, org.jboss.remoting.serialization.impl.jboss, org.jboss.aspects.remoting, org.jboss.web.tomcat.service.sso.spi, org.jboss.jms.server.connectionmanager, org.hibernate.proxy.pojo, org.jaxen.expr, org.jboss.remoting.samples.detection.jndi.ssl, org.jboss.messaging.core.impl.message, org.jboss.security.authorization.resources, org.jboss.metadata.ejb.jboss, org.jboss.ejb.plugins.cmp.jdbc2, antlr.collections, org.jboss.security.cache, javax.enterprise.deploy.model.exceptions, org.jboss.web.tomcat.service.sso.jbc, org.hsqldb.rowio, META-INF, org.jboss.mx.remoting.tracker, org.jboss.mx.remoting.provider.rmi, org.omg.Security, org.jboss.security.xacml.core, com.arjuna.ats.txoj.tools, org.jboss.cache.remoting.jgroups, org.jboss.wsf.spi.metadata.webservices, org.jboss.security.authorization.util, META-INF.maven.org.jboss.cache.jbosscache-core, org.quartz.ee.jmx.jboss, org.hibernate.validator, org.apache.commons.collections.keyvalue, com.arjuna.ats.internal.arjuna.coordinator, org.jacorb.poa.gui, org.omg.CosTypedEventComm, org.jboss.security.xacml.sunxacml.attr.proxy, javax.mail.internet, org.jboss.ha.framework.interfaces, com.arjuna.ats.arjuna.objectstore, org.apache.log4j.lf5.config, org.jboss.metadata.annotation.creator.jboss, org.jboss.invocation.pooled.interfaces, javax.xml.ws.handler, org.jboss.metadata.ejb.jboss.proxy, org.jboss.ejb3.cache, org.jboss.cache.util.concurrent.locks, org.jboss.remoting.samples.transporter.basic.client, com.arjuna.ats.internal.jta.resources, org.quartz.ee.jta, org.hibernate.transaction, org.jboss.security.config, com.arjuna.ats.internal.jta.utils.arjunacore, org.omg.IOP, javax.security.auth.message, org.jboss.ejb3.proxy.clustered.handler.session.stateless, org.jboss.ejb3.cache.tree, org.jboss.remoting.samples.callback.acknowledgement, org.omg.Dynamic, org.jboss.remoting.samples.serialization, org.jboss.cache.notifications, org.omg.DynamicAny.DynAnyPackage, org.jboss.hibernate.jmx, com.sun.mail.iap, META-INF.maven.org.jboss.aspects.jboss-current-invocation-aspects, org.jboss.ejb3.statistics, org.jboss.jms, org.jboss.ejb.plugins.cmp.jdbc.keygen, org.hibernate.cache.jbc2.collection, org.jboss.ejb3.proxy.impl.objectfactory.session.service, org.jboss.cache.factories.context, org.hibernate.intercept, org.apache.commons.logging.impl, com.arjuna.ats.internal.jdbc.recovery, org.jboss.jmx.connector.invoker.serializablepolicy, org.quartz.plugins.history, javax.ejb, org.jboss.ha.singleton, org.apache.avalon.framework.configuration, com.sun.mail.imap, org.apache.commons.collections, org.hibernate.jdbc, org.jboss.ejb.plugins.keygenerator, org.omg.RTCORBA, org.jboss.security.audit, org.jboss.wsf.spi.http, org.jboss.managed.plugins.advice, com.arjuna.ats.internal.jts.orbspecific, org.hsqldb.store, org.slf4j.spi, org.jboss.wsf.spi, org.jboss.remoting.samples.transporter.complex.client, org.jgroups.jmx, org.jboss.jms.recovery, org.jboss.iiop, org.jboss.security.xacml.sunxacml.cond.cluster, org.jboss.ha.jmx.examples, org.jboss.monitor.client, com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate, org.hibernate.secure, org.jboss.metadata, org.jboss.ejb3.tx, org.jboss.security.callbacks, com.arjuna.ats.internal.arjuna.thread, org.jboss.ejb3.interceptors, javax.xml.ws.soap, org.quartz.impl.jdbcjobstore.oracle, org.omg.XA, org.jboss.ejb3.proxy.spi.container, org.jboss.wsf.spi.metadata.j2ee, org.hibernate.cfg, javax.xml.ws.wsaddressing, com.arjuna.ats.internal.jts, org.jboss.management.j2ee.cluster, org.jboss.security.client, com.arjuna.ats.jts.orbspecific.jacorb.interceptors.interposition, org.omg.BiDirPolicy, org.jboss.ejb3.interceptors.metadata, org.jboss.security.plugins.identitytrust, org.hibernate.tool.instrument.javassist, org.jboss.ejb3.remoting, org.jboss.metadata.ejb.jboss.jndipolicy.spi, com.arjuna.ats.internal.jta, org.jboss.security.plugins.javaee, org.omg.CosNotifyCommAck, org.hibernate.cache.jbc2.timestamp, org.omg.GSSUP, org.jaxen.saxpath.base, org.jboss.remoting.network.filter, META-INF.maven.org.jboss.ejb3.jboss-ejb3-interceptors, org.jacorb.notification.impl, org.jboss.remoting.marshal, org.jboss.ejb3.resolvers, org.apache.avalon.framework.container, org.jboss.ejb3.proxy.impl.factory, org.hibernate.cache.impl, org.jboss.serial.exception, org.jboss.proxy.compiler, org.jboss.jpa.deployment, org.hibernate.id.insert, org.jboss.invocation.unified.server, org.jboss.ejb.plugins.cmp.ejbql, org.jboss.logmanager.log4j.filters, org.jboss.remoting.transport.local, org.jboss.cache.invalidation.bridges, org.jaxen.dom, com.arjuna.common.internal.util.logging.jakarta, com.arjuna.ats.arjuna.gandiva, org.omg.CosNotifyComm, org.jboss.cache.loader.bdbje, org.jboss.xnio.channels, org.jboss.ejb3.common.kernel, org.jboss.remoting.marshal.http, org.omg.CONV_FRAME, com.arjuna.ats.arjuna.tools, bsh.util, org.jboss.ejb.plugins, org.apache.log4j.lf5.viewer.categoryexplorer, org.jboss.ejb.txtimer, org.omg.IIOP, org.jboss.serial.references, javax.xml.rpc.handler, org.omg.CosCollection, org.jgroups.blocks, net.jcip.annotations, org.jboss.ejb3.pool, org.hibernate.hql.ast.util, org.jboss.mx.remoting.connector, org.jboss.security.negotiation, org.jboss.security.auth.callback, org.jboss.metadata.annotation.creator.ejb, org.apache.commons.collections.comparators, org.jboss.ejb3.stateless, org.jgroups.protocols, com.arjuna.ats.internal.jdbc.drivers.modifiers, org.jboss.remoting.samples.detection.jndi, org.jboss.ejb3.interceptors.aop.annotation, com.arjuna.ats.arjuna.logging, org.jboss.ejb3.annotation.impl, org.jboss.cache.pojo.interceptors.dynamic, org.jboss.ejb3.mdb.inflow, org.jboss.security.negotiation.spnego, org.jboss.security.authorization.modules.ejb, org.jboss.proxy, org.omg.ATLAS, javax.servlet.resources, org.jboss.cache.interceptors, org.jboss.remoting.samples.chat.server, org.jboss.jms.jndi, org.jboss.aspects.txlock, org.jboss.remoting.transport.https, org.jboss.security.xacml.sunxacml.attr, org.jboss.iiop.csiv2, org.quartz.impl.jdbcjobstore.oracle.weblogic, org.jboss.cache.batch, org.jboss.remoting.transport.coyote.ssl, javax.el, org.jaxen.xom, META-INF.maven.org.jboss.ejb3.jboss-ejb3-metadata, javax.management.j2ee.statistics, com.arjuna.ats.internal.jbossatx.agent, META-INF.maven.org.jboss.javaee.jboss-jaspi-api, org.omg.CORBA.ContainerPackage, org.jboss.ws, com.arjuna.ats.internal.arjuna.gandiva.inventory, org.jboss.ejb3.service, org.jacorb.util.threadpool, config-samples, org.jboss.remoting.samples.chat.client, org.jboss.metadata.validation.validator.ejb, org.jboss.cache.optimistic, org.jboss.ha.framework.server.managed, org.hibernate.ejb.util, org.hibernate.ejb, org.jboss.security.plugins.auth, org.hibernate.dialect.function, org.jboss.cache.io, META-INF.maven.org.jboss.cache.jbosscache-pojo, org.jboss.invocation.http.interfaces, com.arjuna.ats.arjuna.recovery, org.quartz.impl.jdbcjobstore, schema, org.jboss.messaging.core.impl.postoffice, org.jboss.security.authorization, org.jboss.ejb3.cache.simple, META-INF.maven.org.jboss.ejb3.jboss-ejb3-core, org.jboss.ejb3.interceptors.annotation.impl, org.jboss.monitor.services, org.jacorb.sasPolicy, com.arjuna.ats.internal.jbossatx.jts.jca, META-INF.maven.org.jboss.jbossas.jboss-as-security, org.jboss.cache.pojo.collection, org.jboss.profileservice.spi, META-INF.maven.org.jboss.threads.jboss-threads, org.jboss.remoting.socketfactory, org.jboss.profileservice.spi.types, org.apache.commons.collections.list, org.jboss.tm.iiop, com.arjuna.ats.arjuna.common, com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca, org.jboss.jms.server.recovery, org.hibernate.annotations.common.reflection.java.generics, antlr.actions.java, org.jboss.resource.deployment, org.jboss.annotation.ear, META-INF.maven.org.jboss.naming.jnpserver, org.jboss.ha.jndi.impl.jbc, org.hibernate.dialect.lock, org.jboss.remoting.transport.coyote, org.jboss.cache.pojo.impl, org.hibernate.proxy.dom4j, org.omg.CosNotifyChannelAdmin, javax.annotation, org.hibernate.pretty, org.jboss.remoting.transport.multiplex.utility, org.jboss.cache.commands.read, javax.resource, org.hibernate.util, javax.xml.ws.handler.soap, org.omg.CSI, org.jaxen.dom4j, org.jgroups.jmx.protocols.pbcast, org.jacorb.poa.gui.pm, org.jboss.jms.tx, org.jboss.remoting.util.socket, org.jacorb.ir.gui, org.jboss.jmx.connector.invoker.client, org.apache.avalon.framework.component, org.jboss.wsf.spi.management.recording, META-INF.maven.org.jboss.ws.native.jbossws-native-jaxws, org.jboss.ejb3.proxy.impl.factory.session.stateless, com.arjuna.ats.internal.arjuna.state, org.jboss.jpa.deployers, org.hibernate.proxy.pojo.cglib, org.jboss.cache.pojo.jmx, com.sun.mail.pop3, org.jboss.ha.framework.server.lock, org.jacorb.poa.policy, org.jboss.proxy.ejb, org.jboss.messaging.core.impl.memory, org.omg.CSIIOP, org.jboss.remoting.samples.transporter.custom.client, org.jacorb.notification.filter, org.jboss.cache.marshall, org.jboss.security.javaee, META-INF.maven.org.jboss.logging.jboss-logging-jdk, org.apache.log4j.ext, org.apache.bcel.verifier.statics, org.jboss.jms.client.container, org.jboss.metadata.rar.spec, org.jboss.ejb3.proxy.impl.factory.session.stateful, org.apache.bsf.util.event, org.slf4j, META-INF.maven.org.jboss.ejb3.jboss-ejb3-transactions, com.arjuna.common.internal.util.logging, org.jboss.serial.objectmetamodel.safecloning, org.jboss.remoting.samples.transporter.serialization.client, org.jboss.cache.invocation, org.omg.CosTime, org.jboss.logging.jdk.format, org.hibernate.ejb.packaging, org.jboss.ejb3.proxy.clustered.objectfactory.session, com.arjuna.orbportability.debug, javax.persistence.spi, bsh.classpath, org.jacorb.notification.util, com.arjuna.ats.tsmx, org.jboss.ejb.plugins.cmp.bridge, org.jboss.resource.metadata.repository, com.arjuna.ats.tsmx.logging, org.jboss.cache.invalidation, org.jboss.profileservice.aop, org.omg.CORBA.ORBPackage, com.arjuna.ats.internal.jta.transaction.jts, org.jgroups.stack, org.jacorb.orb.standardInterceptors, org.hibernate.cache.impl.bridge, org.jboss.remoting.network, org.jboss.ejb3.cache.impl, org.jboss.security.deployers, org.jboss.ejb3.naming.client.java, org.jboss.ha.jmx, org.jboss.cache.util.reflect, org.jboss.monitor.alarm, org.jacorb.orb.rmi, dtd, org.jboss.security.negotiation.ntlm, org.jboss.cache.commands, org.jboss.metadata.annotation.creator.web, META-INF.maven.org.jboss.aspects.jboss-transaction-aspects, org.jboss.jms.destination, org.jboss.remoting.samples.chat.exceptions, org.jboss.web.deployers, org.jboss.ejb.plugins.security, org.jboss.tm.usertx.interfaces, org.jacorb.notification.container, org.jboss.wsf.common.handler, META-INF.maven.org.jboss.ws.jbossws-spi, javax.servlet.jsp.el, org.jboss.cache.jmx.annotations, org.jboss.remoting.marshal.encryption, org.jboss.ejb3.entity, org.jboss.security.microcontainer.beans, org.jboss.jms.server.jbosssx, org.jboss.jms.client, org.omg.CORBA.ContainedPackage, org.jboss.ejb3.security.client, org.jboss.ha.framework.server, org.jboss.ejb.plugins.inflow, org.apache.log4j.jmx, org.apache.log4j.config, org.jboss.serial, org.jboss.xnio.log, org.jboss.resource.adapter.jdbc.jdk6, org.hibernate.tuple.entity, javax.xml.ws.addressing, org.jboss.tm.usertx.server, org.jacorb.ir.gui.typesystem.remote, META-INF.maven.org.jboss.jbossas.jboss-as-iiop, org.jboss.remoting.marshal.compress, org.jgroups.tests.perf, com.arjuna.ats.internal.jts.orbspecific.coordinator, org.jboss.security.annotation, META-INF.maven.org.jboss.ejb3.jboss-ejb3-deployers, com.arjuna.ats.internal.jta.transaction.arjunacore.jca, org.jboss.metadata.ear.jboss, org.jboss.injection, org.jboss.serial.persister, com.arjuna.ats.jta.exceptions, org.jboss.jms.message, org.hibernate.hql.classic, org.jboss.remoting.util, org.jboss.remoting.samples.transporter.simple, org.jboss.remoting.callback, org.quartz.jobs.ee.ejb, org.jboss.resource.statistic.pool, org.jacorb.orb, com.arjuna.ats.jta.logging, com.arjuna.ats.internal.jts.interposition.resources.arjuna, org.jboss.ejb3.mcint.annotationadaptor, org.hibernate.criterion, javax.transaction, javax.xml.soap, org.jboss.security.xacml.core.model.context, org.jboss.remoting.marshal.rmi, org.jboss.invocation.jrmp.interfaces, org.jboss.security.jacc, org.hibernate.tool.instrument, org.jacorb.orb.factory, org.apache.log4j, org.jboss.ejb3.proxy.clustered.objectfactory, org.jboss.cache.config.parsing, com.arjuna.ats.internal.jts.orbspecific.interposition, org.jacorb.orb.dsi, org.jboss.remoting.samples.transporter.basic.server, org.jboss.ejb3.annotation.defaults, org.jboss.mq.server.jmx, org.jboss.iiop.rmi, org.jboss.metadata.ear.spec, org.jacorb.ir.gui.typesystem, org.jboss.security.plugins, org.jboss.ejb3.proxy.impl, org.omg.CORBA.ValueDefPackage, org.jboss.security.negotiation.prototype, org.apache.commons.collections.bag, org.apache.log4j.chainsaw, org.opennms.protocols.snmp, org.jboss.deployment.spi.factories, org.jboss.security.mapping.config, org.jboss.aspects.remoting.interceptors.transport, org.jboss.wsf.common.injection.resolvers, org.omg.ETF, org.jboss.serial.classmetamodel, org.jacorb.ir.gui.remoteobject, org.jboss.logging.util, com.arjuna.ats.internal.arjuna.recovery, org.apache.bsf.util.event.generator, org.jboss.security.identity.plugins, org.apache.bcel, org.jboss.remoting.transport.http, org.omg.CORBA.portable, com.arjuna.orbportability.event, org.jboss.tm.usertx, org.jboss.remoting.marshall.encryption, org.jboss.cache.commands.legacy, org.jboss.security.auth.message, org.hibernate.loader.hql, org.hibernate.cache.jbc2.access, org.jboss.security.identity.extensions, META-INF.maven.org.jboss.ejb3.jboss-ejb3-common, javax.mail.search, org.jboss.metadata.web.spec, org.hibernate.metadata, org.jboss.security.auth.container.modules, org.jboss.deployment.spi, org.jboss.security.authorization.config, org.jboss.iiop.tm, org.jboss.ejb3.interceptors.util, org.jboss.wsf.framework.deployment, org.hibernate.property, org.jboss.remoting.samples.stream, org.jboss.cache.commands.legacy.read, javax.management.j2ee, org.jboss.mx.remoting.rmi, org.jboss.util, org.jboss.deployment.remoting, org.jnp.interfaces.jnp, org.hibernate.collection, org.jboss.management.j2ee.factory, org.hibernate.exception, org.jboss.wsf.spi.tools.cmd, org.jboss.cache.loader, org.omg.SecurityReplaceable, org.jboss.naming.client.java, org.jboss.cache.interceptors.base, com.sun.mail.util, org.jboss.metadata.rar.jboss.mcf, com.arjuna.orbportability.internal.orbspecific.versions, org.hibernate.param, org.jboss.wsf.spi.invocation.integration, com.arjuna.ats.arjuna.xa, org.jboss.jms.server.plugin, org.jboss.ejb.plugins.cmp.jdbc2.keygen, org.jboss.wsf.common.servlet, org.jboss.cache.commands.write, javax.servlet.jsp.resources, org.jboss.security.plugins.mapping, org.jboss.hibernate.session, org.jacorb.imr.util, org.omg.CosNaming, org.omg.CosNaming.NamingContextExtPackage, org.jboss.remoting.transport.sslbisocket, org.jacorb.imr.AdminPackage, com.sun.mail.imap.protocol, org.jboss.cache, com.arjuna.ats.internal.jts.interposition.resources.restricted, META-INF.maven.org.jboss.aspects.jboss-security-aspects, org.jboss.remoting.transport, org.jboss.jpa.spi, org.apache.bcel.classfile, com.arjuna.ats.internal.arjuna.utils, org.jboss.metadata.client.jboss, org.jboss.ejb3.stateful, antlr.ASdebug, org.omg.PortableServer.POAPackage, org.hibernate.tool.hbm2ddl, org.jboss.jms.referenceable, com.arjuna.ats.internal.jts.coordinator, com.arjuna.ats.arjuna.exceptions, org.hibernate.loader.custom.sql, org.jboss.remoting.samples.callback, com.arjuna.ats.internal.jts.recovery.transactions, com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors, org.jboss.ws.tools.ant, org.hsqldb.types, org.jacorb.security.ssl, org.jboss.iiop.codebase, META-INF.maven.org.hibernate.hibernate-jmx, org.apache.bcel.verifier, org.jboss.security.xacml.factories, org.jacorb.orb.diop, com.arjuna.ats.jdbc.logging, org.jboss.ha.timestamp, org.jboss.ejb.plugins.cmp.jdbc2.bridge, org.jaxen.saxpath, com.arjuna.orbportability.oa.core, antlr.debug, org.jboss.xnio, com.arjuna.common.util.propertyservice.plugins, org.jacorb.concurrency, org.jboss.metadata.process.chain, antlr.actions.csharp, org.jgroups.persistence, org.jboss.security.xacml.sunxacml.finder, org.jboss.remoting.security.domain, org.jacorb.orb.dns, org.jboss.ejb.plugins.cmp.jdbc.bridge, org.jacorb.naming.namemanager, org.jacorb.imr, org.jacorb.poa.gui.beans, org.omg.SecurityLevel1, org.jboss.iiop.rmi.ir, org.omg.SecurityLevel2, org.jboss.jms.server.selector, com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.coordinator, org.hibernate.annotations.common.annotationfactory, org.jboss.ejb3.security.bridge, org.jacorb.notification.queue, com.arjuna.ats.internal.jts.recovery, org.jboss.security.audit.config, org.jboss.remoting.transport.http.ssl, org.jboss.deployment.plugin, org.jboss.cache.mvcc, org.jboss.security.xacml.core.model.policy, org.apache.log4j.net, org.jboss.ejb3.tx.metadata, org.jboss.security.auth.certs, org.jboss.metadata.ejb.jboss.jndipolicy.plugins, antlr.actions.cpp, org.jboss.resource.metadata.mcf, licenses, org.jacorb.config, org.jboss.metadata.common.ejb, org.hibernate.event, javax.resource.spi.endpoint, org.jaxen.function.xslt, com.arjuna.orbportability.oa, org.jboss.ejb3.common.deployers.spi, com.arjuna.ats.internal.jts.context, javax.resource.spi.security, com.arjuna.ats.jts, org.hibernate.cfg.annotations, org.jboss.cache.statetransfer, org.jboss.ejb3.mcint.metadata.plugins, org.jacorb.orb.util, META-INF.maven.org.jboss.cluster.jboss-ha-server-cache-spi, org.omg.CosNotification, org.jboss.ejb3.proxy.impl.jndiregistrar, org.jboss.wsf.framework.management, org.jboss.ejb3.cache.grouped, org.jboss.metadata.javaee.support, org.jboss.ejb3.session, org.jacorb.ssl, org.jboss.remoting.transport.socket, org.quartz.ee.servlet, org.jboss.wsf.common.injection, org.jboss.logging.jdk.xml, org.jboss.security.negotiation.spnego.encoding, org.jboss.profileservice.remoting, com.arjuna.ats.jta, javax.xml.rpc.encoding, javax.enterprise.deploy.spi.factories, org.jboss.security.audit.providers, javax.annotation.security, org.jboss.remoting.transport.sslmultiplex, org.jboss.varia.scheduler, org.jboss.metadata.javaee.spec, org.jboss.logging, org.jboss.jdbc, org.omg.CosTransactions, com.arjuna.ats.internal.jdbc] <IMPORT-ALL>NON_EMPTY}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Wed Jul 29 18:27:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Jul 2009 18:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1691) JBM2 cluster
 fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1419189196.1248906449395.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1691:
-----------------------------------------

    Attachment: build.xml


adding a build.xml for the client part. Copy the libraries into ./lib

> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Clebert Suconic
>         Attachments: build.xml, cluster-nodes-config-files.zip, Jbm2ClusterTest-NodeA.zip, Jbm2ClusterTest-NodeB.zip
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 18:27:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Jul 2009 18:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1691) JBM2
 cluster fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <608939126.1248906449596.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478161#action_12478161 ] 

Clebert Suconic commented on JBMESSAGING-1691:
----------------------------------------------

I will hold working on this issue until Abdel Adridi provides some guidance on how to run this.

Also: We have another task on the roadmap for soak tests anyway.

> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Clebert Suconic
>         Attachments: build.xml, cluster-nodes-config-files.zip, Jbm2ClusterTest-NodeA.zip, Jbm2ClusterTest-NodeB.zip
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 18:29:29 2009
From: jira-events at lists.jboss.org (Abdel Dridi (JIRA))
Date: Wed, 29 Jul 2009 18:29:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1691) JBM2
 cluster fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1888119930.1248906569234.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478162#action_12478162 ] 

Abdel Dridi commented on JBMESSAGING-1691:
------------------------------------------

To replicate the issue, please follow the below steps:

1. In a physical nodeA, configure a live JMB2 micro-container using attached clutered-configuration.
2. In an other physical nodeB, configure a live JBM2 micro-container
3. In NodeA  configure the backup server of Live-NodeB server
4. In NodeB configure the backup server of Live-NodeA server
5. NodeA and NodeB are connected with an Ethernet-cross-cable for fast access.
6. Setup both client project (eclipse project) - make sure that some micro-container/server/lib is in classpath - I forgot to add them to lib.
7. In NodeA run the Junit test case "TestLauncher.testTenantPool()" of eclipse project Jbm2ClusterTest-NodeA.zip.
8. In NodeB run the Junit test case "TestLauncher.testTenantPool()" of eclipse project Jbm2ClusterTest-NodeB.zip.
9. After some time consumer connection will fail after packet-sent timeout - Problem1.
10. then Backup-server will kick-off while Live-server still have live connections which leads to Problem2: more than one broadcasters on the network broadcasting the same node id.
11. I attached a pic of the test case.



> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Clebert Suconic
>         Attachments: build.xml, cluster-nodes-config-files.zip, Jbm2ClusterTest-NodeA.zip, Jbm2ClusterTest-NodeB.zip
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 18:31:29 2009
From: jira-events at lists.jboss.org (Abdel Dridi (JIRA))
Date: Wed, 29 Jul 2009 18:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1691) JBM2 cluster
 fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1132067855.1248906689279.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Abdel Dridi updated JBMESSAGING-1691:
-------------------------------------

    Attachment: jbmTest.JPG


> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Clebert Suconic
>         Attachments: build.xml, cluster-nodes-config-files.zip, Jbm2ClusterTest-NodeA.zip, Jbm2ClusterTest-NodeB.zip, jbmTest.JPG
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 18:33:41 2009
From: jira-events at lists.jboss.org (Rob Stryker (JIRA))
Date: Wed, 29 Jul 2009 18:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMICROCONT-447) Allow changing
 timestamp on a deployment root folder (blah.war) to redeploy
Message-ID: <372720627.1248906821327.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Allow changing timestamp on a deployment root folder (blah.war) to redeploy
---------------------------------------------------------------------------

                 Key: JBMICROCONT-447
                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-447
             Project: JBoss Microcontainer
          Issue Type: Feature Request
          Components: Deployment
            Reporter: Rob Stryker
            Assignee: Ales Justin


If I execute the following, JBoss 5.1 doesn't redeploy a module even though its clearly new. (assuming the module has no descriptor file required)

cd server/default/deploy
rm -rf some.war &&  cp -R /home/rob/tmp/some.war .

Clearly the entire project was removed and a new version coppied over, however the server has not recognized it as new because there is no descriptor. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 18:46:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 18:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-148) DocumentUtil
 transformer output properties
Message-ID: <2080437295.1248907589597.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

DocumentUtil transformer output properties
------------------------------------------

                 Key: JBID-148
                 URL: https://jira.jboss.org/jira/browse/JBID-148
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha4
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1


transformer.setOutputProperty(OutputKeys.INDENT, "no");


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 18:48:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 18:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-148) DocumentUtil
 transformer output properties
In-Reply-To: <2080437295.1248907589597.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2136802067.1248907709774.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-148.
------------------------------

    Resolution: Done


> DocumentUtil transformer output properties
> ------------------------------------------
>
>                 Key: JBID-148
>                 URL: https://jira.jboss.org/jira/browse/JBID-148
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> transformer.setOutputProperty(OutputKeys.INDENT, "no");

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 18:51:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 18:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-149)
 SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
Message-ID: <570484675.1248907889150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
-----------------------------------------------------------------------

                 Key: JBID-149
                 URL: https://jira.jboss.org/jira/browse/JBID-149
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha4
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 18:51:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 18:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-149)
 SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
In-Reply-To: <570484675.1248907889150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <525249845.1248907889271.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-149.
------------------------------

    Resolution: Done


> SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
> -----------------------------------------------------------------------
>
>                 Key: JBID-149
>                 URL: https://jira.jboss.org/jira/browse/JBID-149
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 18:55:44 2009
From: jira-events at lists.jboss.org (Noam Malki (JIRA))
Date: Wed, 29 Jul 2009 18:55:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7134) Modifying
 ManagedOperation to return either a composite value containing a Boolean
 and a String
Message-ID: <600159312.1248908144670.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Modifying ManagedOperation to return either a composite value containing a Boolean and a String
-----------------------------------------------------------------------------------------------

                 Key: JBAS-7134
                 URL: https://jira.jboss.org/jira/browse/JBAS-7134
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Noam Malki
            Assignee: Jesper Pedersen
            Priority: Minor


Returning a composite value containing a Boolean and a String would be useful.

For example, when invoking a test operation it would be useful to get a String  with the specific failure message if the operation failed (please see JOPR-324).


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 19:07:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 19:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7135) Rotated log ends up
 in the wrong directory
Message-ID: <553423281.1248908849311.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Rotated log ends up in the wrong directory
------------------------------------------

                 Key: JBAS-7135
                 URL: https://jira.jboss.org/jira/browse/JBAS-7135
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Logging
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: JBossAS-6.0.0.Alpha1


E.g. server.log.2009.07.26 will be in the directory from which run.sh was executed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 19:09:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 19:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-25) Logging error at
	midnight
Message-ID: <613160271.1248908969362.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Logging error at midnight
-------------------------

                 Key: JBLOGGING-25
                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-25
             Project: JBoss Logging
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: jboss-logmanager
    Affects Versions: 1.1.0.CR5-jboss-logmanager
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 1.1.0.CR6-jboss-logmanager


At midnight, an error occurs because the writer field is read before the pre-log hook and not rechecked in WriterHandler.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 19:09:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 19:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-26) Rotated log ends
 up in the wrong directory
Message-ID: <222944922.1248908969433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Rotated log ends up in the wrong directory
------------------------------------------

                 Key: JBLOGGING-26
                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-26
             Project: JBoss Logging
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: jboss-logmanager
    Affects Versions: 1.1.0.CR5-jboss-logmanager
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 1.1.0.CR6-jboss-logmanager


E.g. server.log.2009.07.26 will be in the directory from which run.sh was executed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 19:30:29 2009
From: jira-events at lists.jboss.org (Abdel Dridi (JIRA))
Date: Wed, 29 Jul 2009 19:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1691) JBM2 cluster
 fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <437808957.1248910229225.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Abdel Dridi updated JBMESSAGING-1691:
-------------------------------------

    Attachment: build.xml


updated build.xml and attached lib.zip that includes all used libs

> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Clebert Suconic
>         Attachments: build.xml, build.xml, cluster-nodes-config-files.zip, Jbm2ClusterTest-NodeA.zip, Jbm2ClusterTest-NodeB.zip, jbmTest.JPG
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 19:32:29 2009
From: jira-events at lists.jboss.org (Abdel Dridi (JIRA))
Date: Wed, 29 Jul 2009 19:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1691) JBM2 cluster
 fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1331625132.1248910349242.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Abdel Dridi updated JBMESSAGING-1691:
-------------------------------------

    Attachment: lib.zip


updated build.xml and attached lib.zip that includes all used libs

> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Clebert Suconic
>         Attachments: build.xml, build.xml, cluster-nodes-config-files.zip, Jbm2ClusterTest-NodeA.zip, Jbm2ClusterTest-NodeB.zip, jbmTest.JPG, lib.zip
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 20:30:29 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Wed, 29 Jul 2009 20:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2199)
 NullPointerException with JPA session persistence in Drools Flow
In-Reply-To: <233050457.1247060645508.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1677063956.1248913829297.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen reassigned JBRULES-2199:
---------------------------------------

    Assignee: Kris Verlaenen  (was: Mark Proctor)


> NullPointerException with JPA session persistence in Drools Flow
> ----------------------------------------------------------------
>
>                 Key: JBRULES-2199
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2199
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Alan Gairey
>            Assignee: Kris Verlaenen
>
> I'm currently using Drools Flow with JPA session persistence enabled as described in section 5.1 of the User Guide.
> As a process executes, session information is saved to the H2 database correctly.
> The problem comes when recreating a session from its persisted state, using the code:
> {code}
> // recreate the session from database using the sessionId
> ksession = JPAKnowledgeService.loadStatefulKnowledgeSession( sessionId, kbase, null, env );
> {code}
> This gives me a NullPointerException.
> Having looked into the Drools Flow source code, I think the problem is in the class drools-persistence-jpa\src\main\java\org\drools\persistence\session\SingleSessionCommandService.java.
> The 4th constructor of this class (starting line 132) is called as part of the loading of a knowledge session from the H2 database (i.e. via the code above); this in turn leads to the afterCompletion method of the inner class SynchronizationImpl being called. The final two lines of this method are:
> {code}
> ((JPAProcessInstanceManager) ((ReteooWorkingMemory) session).getProcessInstanceManager()).clearProcessInstances();
> ((JPAWorkItemManager) ((ReteooWorkingMemory) session).getWorkItemManager()).clearWorkItems();
> {code}
> However, when called via the route described above, the session member variable of SingleSessionCommandService has not been set, thus causing the NullPointerException.
> (Interestingly, running the unit tests for drools-persistence-jpa does result in a NullPointerException being thrown multiple times, although the tests are still listed as having passed.)
> I believe enclosing the above two lines as follows will fix the problem:
> {code}
> if (session != null) { 
>     ((JPAProcessInstanceManager) ((ReteooWorkingMemory) session).getProcessInstanceManager()).clearProcessInstances(); 
>     ((JPAWorkItemManager) ((ReteooWorkingMemory) session).getWorkItemManager()).clearWorkItems(); 
> } 
> {code}
> Also, in the 4th constructor of SingleSessionCommandService, after the session has been set, the following line needs to be added to ensure the session id is the same as the session info id:
> {code}
> ((ReteooStatefulSession) this.session).setId( this.sessionInfo.getId() );
> {code}
> (This line _is_ present at the end of the 3rd constructor - line 123.)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 20:38:29 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Wed, 29 Jul 2009 20:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2201) Rule got
 executed even does not satisfy LHS after firing an external event in Flow
In-Reply-To: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <314900502.1248914309243.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen reassigned JBRULES-2201:
---------------------------------------

    Assignee: Kris Verlaenen  (was: Mark Proctor)


> Rule got executed even does not satisfy LHS after firing an external event in Flow
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2201
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert), drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP SP3, Eclipse 3.4.2
>            Reporter: Kit Chan
>            Assignee: Kris Verlaenen
>            Priority: Critical
>
> I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 20:40:30 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Wed, 29 Jul 2009 20:40:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2201) Rule got
 executed even does not satisfy LHS after firing an external event in Flow
In-Reply-To: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <365313435.1248914430216.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478177#action_12478177 ] 

Kris Verlaenen commented on JBRULES-2201:
-----------------------------------------

Do you have a simple standalone example that could show this behavior?

> Rule got executed even does not satisfy LHS after firing an external event in Flow
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2201
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert), drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP SP3, Eclipse 3.4.2
>            Reporter: Kit Chan
>            Assignee: Kris Verlaenen
>            Priority: Critical
>
> I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 20:42:29 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Wed, 29 Jul 2009 20:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2141) In a rule flow,
 when the action is in MVEL, it is not possible to import classes
In-Reply-To: <5800231.1245931797780.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1810192402.1248914549296.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen reassigned JBRULES-2141:
---------------------------------------

    Assignee: Kris Verlaenen  (was: Mark Proctor)


> In a rule flow, when the action is in MVEL, it is not possible to import classes
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-2141
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2141
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-eclipse (flow)
>    Affects Versions: FUTURE
>            Reporter: Nicolas Heron
>            Assignee: Kris Verlaenen
>
> example : 
> -----------
> Long montant = (Long)context.getVariable("surimposition");
> System.out.println ("Surimposition : '" + montant + "'");
>  filter = new org.drools.runtime.ClassObjectFilter (fr.sopra.impot.Impot.class);
> java.util.Collection impots = context.getKnowledgeRuntime().getObjects(filter);
> if (impots.size()==1) {
> 	Impot impot = (Impot)impots.toArray()[0]; 
> 	impot.setMontantRedressement(montant);
> }
> ---------------
> it says  at design time : 
> Process 'ImpotProcess' [fr.sopra.impot.ImpotProcess]: Action node 'Traitement des resultats' [13] has invalid action: was expecting type: java.lang.Object; but found type: null.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 20:42:29 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Wed, 29 Jul 2009 20:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2118) comment makes
 Work Definition parser fail
In-Reply-To: <30166236.1244728976467.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1559627022.1248914549441.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen reassigned JBRULES-2118:
---------------------------------------

    Assignee: Kris Verlaenen  (was: Mark Proctor)


> comment makes Work Definition parser fail
> -----------------------------------------
>
>                 Key: JBRULES-2118
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2118
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-eclipse (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Eclipse
>            Reporter: Wolfgang Laun
>            Assignee: Kris Verlaenen
>
> See example in Drools Flow, section 8.2.1., Creating the Work Definition: The comment // add more work items here ... makes the parser fail when calling up the RuleFlow editor ("Could not parse work definitions ...: null")

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 21:22:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 21:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBLOGGING-25) Logging error at
	midnight
In-Reply-To: <613160271.1248908969362.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1577030956.1248916949420.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBLOGGING-25.
--------------------------------

    Resolution: Done


> Logging error at midnight
> -------------------------
>
>                 Key: JBLOGGING-25
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-25
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logmanager
>    Affects Versions: 1.1.0.CR5-jboss-logmanager
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 1.1.0.CR6-jboss-logmanager
>
>
> At midnight, an error occurs because the writer field is read before the pre-log hook and not rechecked in WriterHandler.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 21:22:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 21:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBLOGGING-26) Rotated log ends
 up in the wrong directory
In-Reply-To: <222944922.1248908969433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2061652705.1248916949518.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBLOGGING-26.
--------------------------------

    Resolution: Done


> Rotated log ends up in the wrong directory
> ------------------------------------------
>
>                 Key: JBLOGGING-26
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-26
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logmanager
>    Affects Versions: 1.1.0.CR5-jboss-logmanager
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 1.1.0.CR6-jboss-logmanager
>
>
> E.g. server.log.2009.07.26 will be in the directory from which run.sh was executed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 22:17:29 2009
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 29 Jul 2009 22:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2219) UrlResource needs
 to optionally have a cache for remote resources
Message-ID: <1264762667.1248920249480.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

UrlResource needs to optionally have a cache for remote resources
-----------------------------------------------------------------

                 Key: JBRULES-2219
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2219
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-api
    Affects Versions: 5.0.1.FINAL
            Reporter: Michael Neale
            Assignee: Michael Neale
             Fix For: 5.1.0.M1


The knowledge agent uses UrlResource - which is fine for http and https - except when network is down. Would be nice to cache the resource so that it can use a "last known good" version. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 22:35:41 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 22:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBLOGGING-24) Add ability to
 cache logger instances
In-Reply-To: <109580682.1248831509140.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <856163700.1248921341556.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBLOGGING-24.
--------------------------------

    Resolution: Done


> Add ability to cache logger instances
> -------------------------------------
>
>                 Key: JBLOGGING-24
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-24
>             Project: JBoss Logging
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-jdk, jboss-logging-log4j, jboss-logging-spi
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 2.2.0.CR1-jboss-logging
>
>
> The present API/SPI does not allow logger instances to be cached and reused, which can cause unnecessary memory pressure by creating many identical objects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 22:37:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 22:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBLOGGING-23) Add support for
 internationalization and localization with parameterized messages
In-Reply-To: <731548133.1248831389259.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <225946088.1248921449149.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBLOGGING-23.
--------------------------------

    Resolution: Done


> Add support for internationalization and localization with parameterized messages
> ---------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-23
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-23
>             Project: JBoss Logging
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-jdk, jboss-logging-log4j, jboss-logging-spi
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 2.2.0.CR1-jboss-logging
>
>
> The logging API should support optional parameters E.g.:
>     /**
>      * Issue a log message with parameters and a throwable with a level of TRACE.
>      *
>      * @param loggerFqcn the logger class name
>      * @param message the message
>      * @param params the message parameters
>      * @param t the throwable
>      */
>    public void trace(String loggerFqcn, Object message, Object[] params, Throwable t) { ... }
> The logger factory method should allow specification of a resource bundle, e.g.:
>    Logger getLogger(String category, String resourceBundleName) { ... }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 22:43:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 22:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7136) Add complete support
 for internationalized/localized log messages
Message-ID: <89020645.1248921809430.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add complete support for internationalized/localized log messages
-----------------------------------------------------------------

                 Key: JBAS-7136
                 URL: https://jira.jboss.org/jira/browse/JBAS-7136
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Logging
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: JBossAS-6.0.0.Alpha1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 22:45:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 29 Jul 2009 22:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1664) Ordering Group
 is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <614424335.1248921929408.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1664.
-----------------------------------

    Resolution: Done


Done. 

We didn't use those special SQLs for each DB type, rather we use standard jdbc Statement.setFetchSize() to limit the mem usage at the JBM side.



> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 22:45:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 22:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7136) Add complete support
 for internationalized/localized log messages
In-Reply-To: <89020645.1248921809430.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1047065175.1248921929523.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBAS-7136.
-----------------------------

    Resolution: Done


> Add complete support for internationalized/localized log messages
> -----------------------------------------------------------------
>
>                 Key: JBAS-7136
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7136
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: JBossAS-6.0.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 22:45:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 22:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7135) Rotated log ends up
 in the wrong directory
In-Reply-To: <553423281.1248908849311.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1115196315.1248921929637.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBAS-7135.
-----------------------------

    Resolution: Done


> Rotated log ends up in the wrong directory
> ------------------------------------------
>
>                 Key: JBAS-7135
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7135
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> E.g. server.log.2009.07.26 will be in the directory from which run.sh was executed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 22:45:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 22:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7133) Logging error at
	midnight
In-Reply-To: <1226095905.1248903869144.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2080462554.1248921929751.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBAS-7133.
-----------------------------

    Resolution: Done


> Logging error at midnight
> -------------------------
>
>                 Key: JBAS-7133
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7133
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>            Priority: Minor
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> At midnight, we get:
> LogManager error of type WRITE_FAILURE: Error writing log message
> java.io.IOException: Stream closed
> 	at sun.nio.cs.StreamEncoder.ensureOpen(StreamEncoder.java:26)
> 	at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:99)
> 	at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:116)
> 	at java.io.OutputStreamWriter.write(OutputStreamWriter.java:203)
> 	at java.io.Writer.write(Writer.java:140)
> 	at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:65)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:59)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:849)
> 	at org.slf4j.impl.Slf4jLogger.log(Slf4jLogger.java:68)
> 	at org.apache.commons.logging.impl.SLF4JLocationAwareLog.debug(SLF4JLocationAwareLog.java:120)
> 	at com.arjuna.common.internal.util.logging.jakarta.JakartaRelevelingLogger.debug(JakartaRelevelingLogger.java:172)
> 	at com.arjuna.common.internal.util.logging.LogNoi18nImpl.debug(LogNoi18nImpl.java:419)
> 	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:727)
> 	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:412)
> ...because of an order-of-operations error in the base logmanager handler.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 29 23:46:29 2009
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 29 Jul 2009 23:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2219) UrlResource needs
 to optionally have a cache for remote resources
In-Reply-To: <1264762667.1248920249480.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <509285791.1248925589342.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Neale closed JBRULES-2219.
----------------------------------

    Resolution: Done


> UrlResource needs to optionally have a cache for remote resources
> -----------------------------------------------------------------
>
>                 Key: JBRULES-2219
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2219
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-api
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Michael Neale
>            Assignee: Michael Neale
>             Fix For: 5.1.0.M1
>
>
> The knowledge agent uses UrlResource - which is fine for http and https - except when network is down. Would be nice to cache the resource so that it can use a "last known good" version. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 00:01:29 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 30 Jul 2009 00:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JASSIST-91) More modular
	packaging
In-Reply-To: <261113433.1248888149149.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <578240973.1248926489508.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JASSIST-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478186#action_12478186 ] 

Shigeru Chiba commented on JASSIST-91:
--------------------------------------

It is technically possible to minimize the size of the jar file by removing unnecessary components. 
However, the proxy generation needs bytecode generation at the back stage, so the effect would be
smaller than you expected.

> More modular packaging
> ----------------------
>
>                 Key: JASSIST-91
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-91
>             Project: Javassist
>          Issue Type: Feature Request
>            Reporter: Pete Muir
>            Assignee: Shigeru Chiba
>            Priority: Optional
>
> It would great if you could just take the bits of Javassist you need - for example, we only ever use the proxy generation facility, and don't need any of the bytecode generation.
> Motivation is simple - smaller dependencies (in jar file size).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 01:36:29 2009
From: jira-events at lists.jboss.org (Bill Culp (JIRA))
Date: Thu, 30 Jul 2009 01:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7137) MDBs dont register
 local-jndi-name when provided in jboss.xml
Message-ID: <1347556772.1248932189281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

MDBs dont register local-jndi-name when provided in jboss.xml
-------------------------------------------------------------

                 Key: JBAS-7137
                 URL: https://jira.jboss.org/jira/browse/JBAS-7137
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB3
    Affects Versions: JBossAS-5.1.0.GA
         Environment: WIndows, Java 1.6 huge fat fast machine with thousands of terabytes
            Reporter: Bill Culp
            Assignee: Carlo de Wolf


MDBs do not register a JNDI name at all even when local-jndi-name is specified in the jboss.xml and can only be looked up using jboss.j2ee:jar=foo, name=fooname, service=EJB3.

Also start stop destroy create methods as provided for EJB beans in JMX are not provided.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 03:05:29 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 30 Jul 2009 03:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6771) Typo in log
 message of WebServiceDeployerEJB.internalDeploy()
In-Reply-To: <15110409.1239539482895.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2072642806.1248937529210.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478197#action_12478197 ] 

Richard Opalka commented on JBAS-6771:
--------------------------------------

It's not there any more. But we have to wait until JBossWS 3.2.0.Beta2 release is pushed to AS source base to close this issue.

> Typo in log message of WebServiceDeployerEJB.internalDeploy()
> -------------------------------------------------------------
>
>                 Key: JBAS-6771
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6771
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-5.0.1.GA
>            Reporter: Hiranya Samarasekera
>            Assignee: Richard Opalka
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The word "Ignore" is mistyped as "Ingore" in the log message in method internalDeploy()
> log.warn("Ingore ejb deployment with null classname: " + ejb);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 03:18:29 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 30 Jul 2009 03:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7137) MDBs dont register
 local-jndi-name when provided in jboss.xml
In-Reply-To: <1347556772.1248932189281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1837885673.1248938309219.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved JBAS-7137.
---------------------------------

    Resolution: Rejected


MDBs don't have a local business interface, so there are no proxies bound in JNDI.

MDBs are not service MBeans, so they don't have the magic create/start/stop/destroy methods.

Please open a forum post if you want to discuss new use cases.

> MDBs dont register local-jndi-name when provided in jboss.xml
> -------------------------------------------------------------
>
>                 Key: JBAS-7137
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7137
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: WIndows, Java 1.6 huge fat fast machine with thousands of terabytes
>            Reporter: Bill Culp
>            Assignee: Carlo de Wolf
>
> MDBs do not register a JNDI name at all even when local-jndi-name is specified in the jboss.xml and can only be looked up using jboss.j2ee:jar=foo, name=fooname, service=EJB3.
> Also start stop destroy create methods as provided for EJB beans in JMX are not provided.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 03:40:29 2009
From: jira-events at lists.jboss.org (Atul Kumar (JIRA))
Date: Thu, 30 Jul 2009 03:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-759) CLONE -Unable to
 add package after it was added and removed
In-Reply-To: <29684385.1175171941888.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <817587266.1248939629369.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478202#action_12478202 ] 

Atul Kumar commented on JBRULES-759:
------------------------------------

Hi,
 I am using drools 4.0.7 for my applicaiton.

i am getting the same  issue in 

ruleBase.addPackage(rulePackage) method 

when there is multiple drl files with same package name at the provided location.

this does not happen when i use drools 4.0.4 or even drools 5.0.1 version

is this a bug that got introduced in the version 4.0.7  or i am missing something?

we are suppose to evaluate and use 4.0.7 version,

 so wanted to know that whether this issues which was there is 3.0x again reopened in 4.0.7.


> CLONE -Unable to add package after it was added and removed
> -----------------------------------------------------------
>
>                 Key: JBRULES-759
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-759
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 3.0.4
>         Environment: Windows2000 Advanced Server
> JBRules3.0.4
>            Reporter: Brugger Antony
>            Assignee: Edson Tirelli
>             Fix For: 3.0.7, 4.0.0.MR2
>
>
> Unable remove a rule package when it was added after it has been added and removed.
> I have seen the issue  [#JBRULES-358].  My test go a little far than [#JBRULES-358]. 
> I remove the package again when it was added for the seconn time, then an exception was thrown.
>  My test case is:
>     
>     public void testRuleBaseRemove() throws Exception
>     {
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         File file = new File("test.drl");
>         
>         //add and remove
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(new FileReader(file));
>         Package pkg = builder.getPackage();
>         ruleBase.addPackage(pkg);
>         ruleBase.removePackage(pkg.getName());
>         
>         //add and remove again
>         builder = new PackageBuilder();
>         builder.addPackageFromDrl(new FileReader(file));
>         pkg = builder.getPackage();
>         ruleBase.addPackage(pkg);
>         ruleBase.removePackage(pkg.getName());
>     }
> the exception is throw:
> java.lang.NullPointerException
> 	at org.drools.reteoo.HashedObjectSinkList.remove(HashedObjectSinkList.java:102)
> 	at org.drools.reteoo.ObjectTypeNode.remove(ObjectTypeNode.java:245)
> 	at org.drools.reteoo.AlphaNode.remove(AlphaNode.java:211)
> 	at org.drools.reteoo.AlphaNode.remove(AlphaNode.java:211)
> 	at org.drools.reteoo.LeftInputAdapterNode.remove(LeftInputAdapterNode.java:285)
> 	at org.drools.reteoo.TerminalNode.remove(TerminalNode.java:297)
> 	at org.drools.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:589)
> 	at org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:244)
> 	at org.drools.common.AbstractRuleBase.removePackage(AbstractRuleBase.java:338)
> 	at com.zte.ums.uep.pal.fm.osf.rules.core.RuleBaseTest.testRuleBaseRemove(RuleBaseTest.java:71)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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 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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 04:00:29 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 30 Jul 2009 04:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1703) SLSB pooling
 statistics misleading when using ThreadLocalPool
In-Reply-To: <9489125.1233153944280.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1261682643.1248940829696.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf reassigned EJBTHREE-1703:
---------------------------------------

    Assignee: Carlo de Wolf


> SLSB pooling statistics misleading when using ThreadLocalPool
> -------------------------------------------------------------
>
>                 Key: EJBTHREE-1703
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1703
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: pool
>    Affects Versions: AS 4.2.3.GA, 1.0.0-GA
>            Reporter: Galder Zamarreno
>            Assignee: Carlo de Wolf
>            Priority: Critical
>
> SLSB pooling statistics are hugely misleading when using default ThreadLocalPool:
> "The default pooling strategy used by EJB3 SLSBs is a ThreadLocalPool whose maximum is not really 
> quantifiable. The maximum is the maximum number of concurrent threads talking to that EJB3 SLSB 
> that the system can allocate. So, the MaxSize that you see in that JMX view is bogus at least for its 
> current definition of maximum.
> MaxSize - AvailableCount will give you the number of EJB3 SLSBs currently in use, in your case, 0. Again, 
> the meaning of AvailableCount for this pool strategy is not precise.
> CreateCount does represent the number of EJB3 SLSBs that have been created.
> CurrentSize is a bit more complicated to explain. For each thread that uses an EJB3 SLSBs, thread local 
> pool maintains a pool per each thread where there's an instance active in case it's needed again. So, 
> CurrentSize indicates how many of these active instances there are, which assuming that each thread 
> uses only one instance of the bean, matches the number of instances that have been created."
> Example:
> AvailableCount 	int 	R 	30 	MBean Attribute.
> MaxSize 	                int 	R 	30 	MBean Attribute.
> StateString 	        java.lang.String 	R 	Started 	MBean Attribute.
> State 	                int 	R 	3 	MBean Attribute.
> CurrentSize 	        int 	R 	165 	MBean Attribute.
> CreateCount 	        int 	R 	165 	MBean Attribute.
> RemoveCount 	        int 	R 	0 	MBean Attribute.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 04:17:29 2009
From: jira-events at lists.jboss.org (Mirek Sz (JIRA))
Date: Thu, 30 Jul 2009 04:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1878) Injection
 SessionContext in interceptor by ejb-jar.xml
Message-ID: <1400634977.1248941849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Injection SessionContext in interceptor by ejb-jar.xml
------------------------------------------------------

                 Key: EJBTHREE-1878
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1878
             Project: EJB 3.0
          Issue Type: Bug
          Components: injection
    Affects Versions: AS 5.0.0.CR1
         Environment: JBOSS 5.0.0 GA JAVA 1.6_014
            Reporter: Mirek Sz


When I try inject SessionContext by @Resource annotation everything works fine but when I inject it by ejb-jar.xml file I get following error 

full stacttrace:
10:15:00,445 ERROR [FieldBeanProperty] failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
java.lang.IllegalArgumentException: Can not set javax.ejb.SessionContext field test.InterceptorTest.sessionContext to test.SimpleEjbImpl
	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146)
	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150)
	at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:37)
	at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:57)
	at java.lang.reflect.Field.set(Field.java:657)
	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:74)
	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	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.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
10:15:00,445 ERROR [STDERR] java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
10:15:00,446 ERROR [STDERR] 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:99)
10:15:00,446 ERROR [STDERR] 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
10:15:00,462 ERROR [STDERR] 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
10:15:00,462 ERROR [STDERR] 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
10:15:00,463 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10:15:00,463 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
10:15:00,463 ERROR [STDERR] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
10:15:00,463 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Method.java:597)
10:15:00,463 ERROR [STDERR] 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
10:15:00,463 ERROR [STDERR] 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
10:15:00,463 ERROR [StatefulSessionProxyFactoryBase] Could not obtain new Session ID from SFSB Container
javax.ejb.EJBException: java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:423)
	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	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.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
Caused by: java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:99)
	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
	... 15 more


interceptor class

public class InterceptorTest {

	SessionContext sessionContext;
	public Object execute(InvocationContext invocation) throws Exception {
		System.out.println(invocation.getTarget());
		Context context = new InitialContext();
		return invocation.proceed();
	}
}


ejb-jar.xml fragment

<interceptor>
			<interceptor-class>test.InterceptorTest</interceptor-class>
			<around-invoke>
				<method-name>execute</method-name>
			</around-invoke>
			<resource-env-ref>
				<resource-env-ref-name>SessionContext</resource-env-ref-name>
				<resource-env-ref-type>javax.ejb.SessionContext</resource-env-ref-type>
				<injection-target>
					<injection-target-class>test.InterceptorTest</injection-target-class>
					<injection-target-name>sessionContext</injection-target-name>
				</injection-target>
			</resource-env-ref>
		</interceptor>




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 04:19:29 2009
From: jira-events at lists.jboss.org (Atul Kumar (JIRA))
Date: Thu, 30 Jul 2009 04:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2220) getting Issues
 with ruleBase.addPackage(rulePackage) in drools 4.0.7 where it works for
 drools4.0.4 and even drools 5.0.1
Message-ID: <1965023420.1248941969168.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

getting Issues with ruleBase.addPackage(rulePackage) in drools 4.0.7 where it works for drools4.0.4 and even drools 5.0.1
-------------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2220
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2220
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core  (expert)
    Affects Versions: 4.0.7
         Environment: WindowsXP
            Reporter: Atul Kumar
            Assignee: Mark Proctor
             Fix For: 4.0.4


Hi, 
 I am using drools 4.0.7 for my applicaiton. 

i am getting the same issue in 

ruleBase.addPackage(rulePackage) method 

when there is multiple drl files with same package name at the provided location. 

this does not happen when i use drools 4.0.4 or even drools 5.0.1 version 

is this a bug that got introduced in the version 4.0.7 or i am missing something? 

we are suppose to evaluate and use 4.0.7 version, 

 so wanted to know that whether this issues which was there is 3.0x again reopened in 4.0.7. 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 04:23:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 30 Jul 2009 04:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1878) Injection
 SessionContext in interceptor by ejb-jar.xml
In-Reply-To: <1400634977.1248941849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1565711415.1248942209326.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned EJBTHREE-1878:
--------------------------------------

    Assignee: jaikiran pai


> Injection SessionContext in interceptor by ejb-jar.xml
> ------------------------------------------------------
>
>                 Key: EJBTHREE-1878
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1878
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: injection
>    Affects Versions: AS 5.0.0.CR1
>         Environment: JBOSS 5.0.0 GA JAVA 1.6_014
>            Reporter: Mirek Sz
>            Assignee: jaikiran pai
>
> When I try inject SessionContext by @Resource annotation everything works fine but when I inject it by ejb-jar.xml file I get following error 
> full stacttrace:
> 10:15:00,445 ERROR [FieldBeanProperty] failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> java.lang.IllegalArgumentException: Can not set javax.ejb.SessionContext field test.InterceptorTest.sessionContext to test.SimpleEjbImpl
> 	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146)
> 	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150)
> 	at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:37)
> 	at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:57)
> 	at java.lang.reflect.Field.set(Field.java:657)
> 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:74)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
> 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
> 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
> 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
> 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
> 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
> 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
> 10:15:00,445 ERROR [STDERR] java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> 10:15:00,446 ERROR [STDERR] 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:99)
> 10:15:00,446 ERROR [STDERR] 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
> 10:15:00,463 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 10:15:00,463 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 10:15:00,463 ERROR [STDERR] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 10:15:00,463 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Method.java:597)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
> 10:15:00,463 ERROR [StatefulSessionProxyFactoryBase] Could not obtain new Session ID from SFSB Container
> javax.ejb.EJBException: java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:423)
> 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
> 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
> Caused by: java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:99)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
> 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
> 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
> 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
> 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
> 	... 15 more
> interceptor class
> public class InterceptorTest {
> 	SessionContext sessionContext;
> 	public Object execute(InvocationContext invocation) throws Exception {
> 		System.out.println(invocation.getTarget());
> 		Context context = new InitialContext();
> 		return invocation.proceed();
> 	}
> }
> ejb-jar.xml fragment
> <interceptor>
> 			<interceptor-class>test.InterceptorTest</interceptor-class>
> 			<around-invoke>
> 				<method-name>execute</method-name>
> 			</around-invoke>
> 			<resource-env-ref>
> 				<resource-env-ref-name>SessionContext</resource-env-ref-name>
> 				<resource-env-ref-type>javax.ejb.SessionContext</resource-env-ref-type>
> 				<injection-target>
> 					<injection-target-class>test.InterceptorTest</injection-target-class>
> 					<injection-target-name>sessionContext</injection-target-name>
> 				</injection-target>
> 			</resource-env-ref>
> 		</interceptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 04:23:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 30 Jul 2009 04:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1566) Temporary
 Destinations should not allow their consumers to be created on other
 connections than their own as per JMS spec
In-Reply-To: <18089367.1238683225226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <328224984.1248942209573.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1566.
------------------------------------

    Resolution: Done
      Assignee: Jeff Mesnil  (was: Tim Fox)


fixed in the trunk

> Temporary Destinations should not allow their consumers to be created on other connections than their own as per JMS spec
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1566
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1566
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Howard Gao
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> JMS 1.1 spec Section 4.4.3 2nd paragraph:
> Temporary destinations (TemporaryQueue or TemporaryTopic objects) are
> destinations that are system-generated uniquely for their connection. Only
> their own connection is allowed to create MessageConsumers for them.
> So the following test should fail, but currently it passes.
>    public void testTemporaryQueueScope()
>    {
>       try
>       {
>          senderConnection.stop();
>          receiverConnection.stop();
>          tempQueue = receiverSession.createTemporaryQueue();
>          //create consumer on different connection, should fail!
>          senderSession.createConsumer(tempQueue);
>       }
>       catch (JMSException e)
>       {
>          fail(e);
>       }
>    }
> The same issue exists with temporary topics too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 04:26:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 30 Jul 2009 04:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1878) Injection
 SessionContext in interceptor by ejb-jar.xml
In-Reply-To: <1400634977.1248941849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1821904932.1248942389172.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1878:
-----------------------------------

          Component/s: core
                           (was: injection)
    Affects Version/s: 1.0.0-Beta10
                           (was: AS 5.0.0.CR1)


> Injection SessionContext in interceptor by ejb-jar.xml
> ------------------------------------------------------
>
>                 Key: EJBTHREE-1878
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1878
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.0.0-Beta10
>         Environment: JBOSS 5.0.0 GA JAVA 1.6_014
>            Reporter: Mirek Sz
>            Assignee: jaikiran pai
>
> When I try inject SessionContext by @Resource annotation everything works fine but when I inject it by ejb-jar.xml file I get following error 
> full stacttrace:
> 10:15:00,445 ERROR [FieldBeanProperty] failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> java.lang.IllegalArgumentException: Can not set javax.ejb.SessionContext field test.InterceptorTest.sessionContext to test.SimpleEjbImpl
> 	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146)
> 	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150)
> 	at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:37)
> 	at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:57)
> 	at java.lang.reflect.Field.set(Field.java:657)
> 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:74)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
> 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
> 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
> 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
> 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
> 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
> 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
> 10:15:00,445 ERROR [STDERR] java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> 10:15:00,446 ERROR [STDERR] 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:99)
> 10:15:00,446 ERROR [STDERR] 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
> 10:15:00,463 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 10:15:00,463 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 10:15:00,463 ERROR [STDERR] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 10:15:00,463 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Method.java:597)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
> 10:15:00,463 ERROR [StatefulSessionProxyFactoryBase] Could not obtain new Session ID from SFSB Container
> javax.ejb.EJBException: java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:423)
> 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
> 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
> Caused by: java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:99)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
> 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
> 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
> 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
> 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
> 	... 15 more
> interceptor class
> public class InterceptorTest {
> 	SessionContext sessionContext;
> 	public Object execute(InvocationContext invocation) throws Exception {
> 		System.out.println(invocation.getTarget());
> 		Context context = new InitialContext();
> 		return invocation.proceed();
> 	}
> }
> ejb-jar.xml fragment
> <interceptor>
> 			<interceptor-class>test.InterceptorTest</interceptor-class>
> 			<around-invoke>
> 				<method-name>execute</method-name>
> 			</around-invoke>
> 			<resource-env-ref>
> 				<resource-env-ref-name>SessionContext</resource-env-ref-name>
> 				<resource-env-ref-type>javax.ejb.SessionContext</resource-env-ref-type>
> 				<injection-target>
> 					<injection-target-class>test.InterceptorTest</injection-target-class>
> 					<injection-target-name>sessionContext</injection-target-name>
> 				</injection-target>
> 			</resource-env-ref>
> 		</interceptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 04:28:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 30 Jul 2009 04:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1676) Jboss
	Messaging deadlock
In-Reply-To: <317741887.1246538691801.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1025128456.1248942509244.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478208#action_12478208 ] 

Howard Gao commented on JBMESSAGING-1676:
-----------------------------------------

Hi Daniel,

Along the stack there is no locking in JBM source code. It's probably from JCA.

Howard


> Jboss Messaging deadlock
> ------------------------
>
>                 Key: JBMESSAGING-1676
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1676
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: AS Integration
>    Affects Versions: 1.4.3.GA
>         Environment: Version:Linux 2.6.18-53.el5
> Description:Linux Operating System
> Traits
> OS Name: Linux
> OS Version: 2.6.18-53.el5
> Architecture: i386
> Distribution Name: CentOS
> Distribution Version: release 5 (Final)
>            Reporter: Daniel Cullender
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Under high concurrent load it appears that jboss messaging gets stuck in the Hashmap.put method which causes the threads to deadlock which in turn causes transaction timeouts.
> We have several mdb's which have max session sizes of 150, we have max strict pool size of 150 and the jboss thread pool size of 50.
> Recently upgraded from jboss AS 4 MQ series to jboss 5 AS with jboss messaging 1.4.3.GA, with JbossMQ  this problem did not occur.
> The stack trace of the problem is as follows :
> Thread: WorkManager(2)-50 : priority:5, demon:true, threadId:147,
> threadState:RUNNABLE
> java.util.HashMap.put(HashMap.java:374)
> java.util.HashSet.add(HashSet.java:200)
> org.jboss.jms.client.state.HierarchicalStateSupport.(HierarchicalStateSupport.java:63)
> org.jboss.jms.client.state.ProducerState.(ProducerState.java:68)
> org.jboss.jms.client.container.StateCreationAspect.handleCreateProducerDelegate(StateCreationAspect.java:180)
> org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateProducerDelegate_30485827.invoke(StateCreationAspect_z_handleCreateProducerDelegate_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.delegate.ClientSessionDelegate.createProducerDelegate(ClientSessionDelegate.java)
> org.jboss.jms.client.JBossSession.createProducer(JBossSession.java:209)
> qut.common.dao.JmsDao.publishMessage(JmsDao.java:66)
> qut.common.dao.JmsDao.publish(JmsDao.java:104)
> qut.order.manager.OrderManagerMBean.publish(OrderManagerMBean.java:156)
> qut.order.manager.OrderManagerMBean.process(OrderManagerMBean.java:98)
> sun.reflect.GeneratedMethodAccessor354.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
> sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
> org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:451)
> org.jboss.ejb3.service.ServiceMBeanDelegate.invoke(ServiceMBeanDelegate.java:215)
> org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> $Proxy1543.process(Unknown Source)
> qut.order.mdb.OrderManagerTradingDataMDBean.onMessage(OrderManagerTradingDataMDBean.java:64)
> sun.reflect.GeneratedMethodAccessor353.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor$InvocationContext.proceed(InvocationContextInterceptor.java:138)
> qut.common.interceptor.ConcurrencyInterceptor.myInterceptor(ConcurrencyInterceptor.java:46)
> sun.reflect.GeneratedMethodAccessor320.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:83)
> org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:70)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:59)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
> sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
> org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:80)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:282)
> org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:270)
> org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:140)
> $Proxy389.onMessage(Unknown Source)
> org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:178)
> org.jboss.jms.client.container.ClientConsumer.callOnMessageStatic(ClientConsumer.java:160)
> org.jboss.jms.client.container.SessionAspect.handleRun(SessionAspect.java:831)
> org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleRun_30485827.invoke(SessionAspect_z_handleRun_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.delegate.ClientSessionDelegate.run(ClientSessionDelegate.java)
> org.jboss.jms.client.JBossSession.run(JBossSession.java:199)
> org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:234)
> org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205)
> org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> java.lang.Thread.run(Thread.java:619)
> Locked synchronizers : 
> - locked <0x535d1e> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> Thread: WorkManager(2)-70 : priority:5, demon:true, threadId:168,
> threadState:RUNNABLE
> java.util.HashMap.put(HashMap.java:374)
> java.util.HashSet.add(HashSet.java:200)
> org.jboss.jms.client.state.HierarchicalStateSupport.(HierarchicalStateSupport.java:63)
> org.jboss.jms.client.state.ProducerState.(ProducerState.java:68)
> org.jboss.jms.client.container.StateCreationAspect.handleCreateProducerDelegate(StateCreationAspect.java:180)
> org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateProducerDelegate_30485827.invoke(StateCreationAspect_z_handleCreateProducerDelegate_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.delegate.ClientSessionDelegate.createProducerDelegate(ClientSessionDelegate.java)
> org.jboss.jms.client.JBossSession.createProducer(JBossSession.java:209)
> qut.common.dao.JmsDao.publishMessage(JmsDao.java:66)
> qut.common.dao.JmsDao.publish(JmsDao.java:104)
> qut.order.manager.OrderManagerMBean.publish(OrderManagerMBean.java:156)
> qut.order.manager.OrderManagerMBean.process(OrderManagerMBean.java:98)
> sun.reflect.GeneratedMethodAccessor354.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
> sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
> org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:451)
> org.jboss.ejb3.service.ServiceMBeanDelegate.invoke(ServiceMBeanDelegate.java:215)
> org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> $Proxy1384.process(Unknown Source)
> qut.order.mdb.OrderManagerTradingDataMDBean.onMessage(OrderManagerTradingDataMDBean.java:64)
> sun.reflect.GeneratedMethodAccessor353.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor$InvocationContext.proceed(InvocationContextInterceptor.java:138)
> qut.common.interceptor.ConcurrencyInterceptor.myInterceptor(ConcurrencyInterceptor.java:46)
> sun.reflect.GeneratedMethodAccessor320.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:83)
> org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:70)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:59)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
> sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
> org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:80)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:282)
> org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:270)
> org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:140)
> $Proxy389.onMessage(Unknown Source)
> org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:178)
> org.jboss.jms.client.container.ClientConsumer.callOnMessageStatic(ClientConsumer.java:160)
> org.jboss.jms.client.container.SessionAspect.handleRun(SessionAspect.java:831)
> org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleRun_30485827.invoke(SessionAspect_z_handleRun_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.delegate.ClientSessionDelegate.run(ClientSessionDelegate.java)
> org.jboss.jms.client.JBossSession.run(JBossSession.java:199)
> org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:234)
> org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205)
> org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> java.lang.Thread.run(Thread.java:619)
> Locked synchronizers : 
> - locked <0x18827b6> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 04:28:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 30 Jul 2009 04:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1878) Injection of
 SessionContext in interceptor by ejb-jar.xml fails
In-Reply-To: <1400634977.1248941849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1792202565.1248942509368.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1878:
-----------------------------------

                   Summary: Injection of SessionContext in interceptor by ejb-jar.xml fails  (was: Injection SessionContext in interceptor by ejb-jar.xml)
    Workaround Description: Using @Resource annotation in the interceptor class for SessionContext injection works. See the forum thread for details.
                Workaround: [Workaround Exists]


> Injection of SessionContext in interceptor by ejb-jar.xml fails
> ---------------------------------------------------------------
>
>                 Key: EJBTHREE-1878
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1878
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.0.0-Beta10
>         Environment: JBOSS 5.0.0 GA JAVA 1.6_014
>            Reporter: Mirek Sz
>            Assignee: jaikiran pai
>
> When I try inject SessionContext by @Resource annotation everything works fine but when I inject it by ejb-jar.xml file I get following error 
> full stacttrace:
> 10:15:00,445 ERROR [FieldBeanProperty] failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> java.lang.IllegalArgumentException: Can not set javax.ejb.SessionContext field test.InterceptorTest.sessionContext to test.SimpleEjbImpl
> 	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146)
> 	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150)
> 	at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:37)
> 	at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:57)
> 	at java.lang.reflect.Field.set(Field.java:657)
> 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:74)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
> 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
> 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
> 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
> 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
> 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
> 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
> 10:15:00,445 ERROR [STDERR] java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> 10:15:00,446 ERROR [STDERR] 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:99)
> 10:15:00,446 ERROR [STDERR] 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
> 10:15:00,463 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 10:15:00,463 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 10:15:00,463 ERROR [STDERR] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 10:15:00,463 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Method.java:597)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
> 10:15:00,463 ERROR [StatefulSessionProxyFactoryBase] Could not obtain new Session ID from SFSB Container
> javax.ejb.EJBException: java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:423)
> 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
> 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
> Caused by: java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:99)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
> 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
> 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
> 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
> 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
> 	... 15 more
> interceptor class
> public class InterceptorTest {
> 	SessionContext sessionContext;
> 	public Object execute(InvocationContext invocation) throws Exception {
> 		System.out.println(invocation.getTarget());
> 		Context context = new InitialContext();
> 		return invocation.proceed();
> 	}
> }
> ejb-jar.xml fragment
> <interceptor>
> 			<interceptor-class>test.InterceptorTest</interceptor-class>
> 			<around-invoke>
> 				<method-name>execute</method-name>
> 			</around-invoke>
> 			<resource-env-ref>
> 				<resource-env-ref-name>SessionContext</resource-env-ref-name>
> 				<resource-env-ref-type>javax.ejb.SessionContext</resource-env-ref-type>
> 				<injection-target>
> 					<injection-target-class>test.InterceptorTest</injection-target-class>
> 					<injection-target-name>sessionContext</injection-target-name>
> 				</injection-target>
> 			</resource-env-ref>
> 		</interceptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 05:28:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 30 Jul 2009 05:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1017) GossipRouter:
 start() doesn't return - unit tests will block
Message-ID: <2025090477.1248946109242.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

GossipRouter: start() doesn't return - unit tests will block
------------------------------------------------------------

                 Key: JGRP-1017
                 URL: https://jira.jboss.org/jira/browse/JGRP-1017
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.8


We need to revert the change where we made start() call mainLoop() directly, this needs to run in a seperate thread. Or, we pass a boolean to start() which defines whether to call mainLoop() on a separate thread, or not.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 05:48:30 2009
From: jira-events at lists.jboss.org (Hans-Joerg Adel (JIRA))
Date: Thu, 30 Jul 2009 05:48:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JASSIST-83) NullPointerException
 in Handler#getType
In-Reply-To: <2275005.1244109956457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <263565181.1248947310126.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hans-Joerg Adel closed JASSIST-83.
----------------------------------



Everything ok.

> NullPointerException in Handler#getType
> ---------------------------------------
>
>                 Key: JASSIST-83
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-83
>             Project: Javassist
>          Issue Type: Bug
>         Environment: JA version 3.4, Windows Vista and JDK 1.6.0_10
>            Reporter: Hans-Joerg Adel
>            Assignee: Shigeru Chiba
>            Priority: Optional
>             Fix For: 3.11.0.GA
>
>         Attachments: Sample.java, SampleClass.java
>
>
> Hi!
> When I use ExprEditor#edit(Handler) to access a try-statement without a catch-clause I get a NullPointerException. 
> To reproduce the bug, please use this source
> /*--- (C) 1999-2008 Techniker Krankenkasse ---*/
> package samplepackage;
> import javassist.CannotCompileException;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.NotFoundException;
> import javassist.expr.ExprEditor;
> import javassist.expr.Handler;
> public class Sample {
> 	public static void main(String[] args) throws NotFoundException, CannotCompileException {
> 		ClassPool classPool = ClassPool.getDefault();
> 		CtClass ctClass = classPool.get("samplepackage.SampleClass");
> 		ctClass.instrument(new MyExprEditor());
> 	}
> 	static class MyExprEditor extends ExprEditor {
> 		@Override
> 		public void edit(Handler h) throws CannotCompileException {
> 			try {
> 				h.getType();
> 			} catch (NotFoundException e) {
> 			}
> 		}
> 	}
> }
> Stacktrace:
> Exception in thread "main" java.lang.NullPointerException
> 	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:517)
> 	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:499)
> 	at javassist.expr.Handler.getType(Handler.java:76)
> 	at samplepackage.Sample$MyExprEditor.edit(Sample.java:25)
> 	at javassist.expr.ExprEditor.doit(ExprEditor.java:97)
> 	at javassist.CtClassType.instrument(CtClassType.java:1224)
> 	at samplepackage.Sample.main(Sample.java:17)
> I would expect that h.getType() returns null.
> I am using JA version 3.4, Windows Vista and JDK 1.6.0_10.
> Cheers
> Ruwen
> iA Hans-Joerg Adel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 05:52:29 2009
From: jira-events at lists.jboss.org (Hans-Joerg Adel (JIRA))
Date: Thu, 30 Jul 2009 05:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-92) ExprEditor: edit
 "throw new Exception"-Statements
Message-ID: <19753949.1248947549788.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

ExprEditor: edit "throw new Exception"-Statements
-------------------------------------------------

                 Key: JASSIST-92
                 URL: https://jira.jboss.org/jira/browse/JASSIST-92
             Project: Javassist
          Issue Type: Feature Request
    Affects Versions: 3.11.0.GA
         Environment: WIndows Vista Java 1.6
            Reporter: Hans-Joerg Adel
            Assignee: Shigeru Chiba
            Priority: Minor


Hi!

At the moment I am using the ExprEditor. I miss an edit-Method to access throw statements like the follwing ones:

throw new RuntimeException();

try {
   foobar(x);
} catch (IllegalArgumentException e) {
   doSomething();
   throw e; // this statement
}


I think of something like this:

public void edit(ThrowExpr t) {
     t.getType(); // returns the CtClass of the thrown Exception
}

Cheers
Ruwen and Hans-Joerg

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 06:03:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 30 Jul 2009 06:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1561)
 ConnectionFactoryCallbackHandler$CallbackConnectionListener should call
 disconnectTimeout(0) in connection failure handling
In-Reply-To: <11075112.1238392560731.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <763518776.1248948209881.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1561.
-----------------------------------

    Resolution: Done


In ClientClusteredConnectionFactoryDelegate.closeCallback() a boolean parameter is added to the method to indicate the reason for closing the callback. If this parameter is passed true, it calls remoting.setFailed() rather than stop().



> ConnectionFactoryCallbackHandler$CallbackConnectionListener should call disconnectTimeout(0) in connection failure handling
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1561
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1561
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.2.GA.SP1
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In ConnectionFactoryCallbackHandler$CallbackConnectionListener, the failure handling will close/stop the old remoting client and create/start a new one. The close/stop will call Client.disconnect() in the end. It should be called the Client.setDisconnectTimeout(0) before the disconnect call, so that the client will not attempt to do any remote calls in the closing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 06:15:29 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 30 Jul 2009 06:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-447) Create pom for
	testsuite
In-Reply-To: <22719663.1200604699244.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <508634577.1248948929986.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478219#action_12478219 ] 

Richard Opalka commented on JBBUILD-447:
----------------------------------------

Is the following failure somehow related to AS trunk build failure? I'm getting:

[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] An Ant BuildException has occured: The following error occurred while executing this line:
Target "dist" does not exist in the project "JBoss/Testsuite". 

and don't know wheter create new JIRA issue, or not?

> Create pom for testsuite
> ------------------------
>
>                 Key: JBBUILD-447
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-447
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> The testsuite module of the app server build needs a maven pom.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 06:15:30 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 30 Jul 2009 06:15:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-447) Create pom for
	testsuite
In-Reply-To: <22719663.1200604699244.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1876515937.1248948930106.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated JBBUILD-447:
-----------------------------------

    Comment: was deleted


> Create pom for testsuite
> ------------------------
>
>                 Key: JBBUILD-447
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-447
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> The testsuite module of the app server build needs a maven pom.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 06:15:30 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 30 Jul 2009 06:15:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-447) Create pom for
	testsuite
In-Reply-To: <22719663.1200604699244.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <663945383.1248948930238.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478220#action_12478220 ] 

Richard Opalka commented on JBBUILD-447:
----------------------------------------

Is the following failure somehow related to this issue? 

[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] An Ant BuildException has occured: The following error occurred while executing this line:
Target "dist" does not exist in the project "JBoss/Testsuite".

and don't know wheter create new JIRA issue, or not? 

> Create pom for testsuite
> ------------------------
>
>                 Key: JBBUILD-447
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-447
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> The testsuite module of the app server build needs a maven pom.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 07:02:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 30 Jul 2009 07:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-447) Create pom for
	testsuite
In-Reply-To: <22719663.1200604699244.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <125475898.1248951749306.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478226#action_12478226 ] 

Paul Gier commented on JBBUILD-447:
-----------------------------------

The problem is related to JBBUILD-539.  It should be fixed now.

> Create pom for testsuite
> ------------------------
>
>                 Key: JBBUILD-447
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-447
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> The testsuite module of the app server build needs a maven pom.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 07:07:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 30 Jul 2009 07:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1550) Core
 BridgeConfiguration with a discovery group is not deployed
In-Reply-To: <22813655.1237480462871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <492969544.1248952049200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1550.
------------------------------------

    Resolution: Done


fixed in the trunk

> Core BridgeConfiguration with a discovery group is not deployed
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1550
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1550
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> A Core BridgeConfiguration can be set with either a discovery group or a pair of connectors.
> When the bridge is deployed (in ClusterManager.start()), we only check for the pair of connectors.
> If the bridge config uses a discovery group, it will never be deployed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 08:04:29 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 30 Jul 2009 08:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7138) Update JBossWS to
	3.2.0.GA
Message-ID: <1764228945.1248955469338.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Update JBossWS to 3.2.0.GA
--------------------------

                 Key: JBAS-7138
                 URL: https://jira.jboss.org/jira/browse/JBAS-7138
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Richard Opalka
            Assignee: Richard Opalka
             Fix For: JBossAS-5.2.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 08:36:29 2009
From: jira-events at lists.jboss.org (Bulat Nigmatullin (JIRA))
Date: Thu, 30 Jul 2009 08:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1018)
 TP.sendToSingleMember NullPointerException
Message-ID: <847418881.1248957389599.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

TP.sendToSingleMember NullPointerException
------------------------------------------

                 Key: JGRP-1018
                 URL: https://jira.jboss.org/jira/browse/JGRP-1018
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.8
         Environment: Ubuntu Linux 9.04 64-bit
            Reporter: Bulat Nigmatullin
            Assignee: Bela Ban


2009.07.30 16:28:47 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 2a1f5231-474b-aa1c-976d-70f5b32265af (108 bytes)
java.lang.NullPointerException
        at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
        at org.jgroups.protocols.TP.doSend(TP.java:1090)
        at org.jgroups.protocols.TP.send(TP.java:1073)
        at org.jgroups.protocols.TP.down(TP.java:934)
        at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
        at org.jgroups.protocols.Discovery.down(Discovery.java:411)
        at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
        at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
        at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
        at org.jgroups.protocols.FD.down(FD.java:300)
        at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:76)
        at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1436)
        at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1382)
        at org.jgroups.protocols.pbcast.NAKACK.stable(NAKACK.java:1354)
        at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:581)
        at org.jgroups.protocols.UNICAST.down(UNICAST.java:408)
        at org.jgroups.protocols.pbcast.STABLE.handleStabilityMessage(STABLE.java:622)
        at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:247)
        at org.jgroups.protocols.UNICAST.up(UNICAST.java:297)
        at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:823)
        at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:686)
        at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
        at org.jgroups.protocols.FD.up(FD.java:265)
        at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:271)
        at org.jgroups.stack.Protocol.up(Protocol.java:336)
        at org.jgroups.protocols.Discovery.up(Discovery.java:234)
        at org.jgroups.stack.Protocol.up(Protocol.java:336)
        at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
        at org.jgroups.protocols.TP.access$100(TP.java:53)
        at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
        at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
2009.07.30 16:28:58 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 38d9e5b6-4d65-20b4-7b41-7c6658e928d6 (172 bytes)
java.lang.NullPointerException
        at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
        at org.jgroups.protocols.TP.doSend(TP.java:1090)
        at org.jgroups.protocols.TP.send(TP.java:1073)
        at org.jgroups.protocols.TP.down(TP.java:934)
        at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
        at org.jgroups.protocols.Discovery.down(Discovery.java:411)
        at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
        at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
        at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
        at org.jgroups.protocols.FD.down(FD.java:300)
        at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
        at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
        at org.jgroups.protocols.FD.up(FD.java:265)
        at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
        at org.jgroups.stack.Protocol.up(Protocol.java:336)
        at org.jgroups.protocols.Discovery.up(Discovery.java:234)
        at org.jgroups.stack.Protocol.up(Protocol.java:336)
        at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
        at org.jgroups.protocols.TP.access$100(TP.java:53)
        at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
        at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 08:51:41 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 30 Jul 2009 08:51:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1018)
 TP.sendToSingleMember NullPointerException
In-Reply-To: <847418881.1248957389599.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1951757341.1248958301581.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1018:
---------------------------

    Fix Version/s: 2.8


> TP.sendToSingleMember NullPointerException
> ------------------------------------------
>
>                 Key: JGRP-1018
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1018
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.8
>         Environment: Ubuntu Linux 9.04 64-bit
>            Reporter: Bulat Nigmatullin
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> 2009.07.30 16:28:47 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 2a1f5231-474b-aa1c-976d-70f5b32265af (108 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:76)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1436)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1382)
>         at org.jgroups.protocols.pbcast.NAKACK.stable(NAKACK.java:1354)
>         at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:581)
>         at org.jgroups.protocols.UNICAST.down(UNICAST.java:408)
>         at org.jgroups.protocols.pbcast.STABLE.handleStabilityMessage(STABLE.java:622)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:247)
>         at org.jgroups.protocols.UNICAST.up(UNICAST.java:297)
>         at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:823)
>         at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:686)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:271)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> 2009.07.30 16:28:58 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 38d9e5b6-4d65-20b4-7b41-7c6658e928d6 (172 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 08:53:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 30 Jul 2009 08:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1018)
 TP.sendToSingleMember NullPointerException
In-Reply-To: <847418881.1248957389599.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <864111734.1248958409168.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478240#action_12478240 ] 

Bela Ban commented on JGRP-1018:
--------------------------------

Can you try this with the latest from CVS head ? sendToSingleMember() doesn't exist anymore, it is sendUnicast() now

> TP.sendToSingleMember NullPointerException
> ------------------------------------------
>
>                 Key: JGRP-1018
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1018
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.8
>         Environment: Ubuntu Linux 9.04 64-bit
>            Reporter: Bulat Nigmatullin
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> 2009.07.30 16:28:47 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 2a1f5231-474b-aa1c-976d-70f5b32265af (108 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:76)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1436)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1382)
>         at org.jgroups.protocols.pbcast.NAKACK.stable(NAKACK.java:1354)
>         at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:581)
>         at org.jgroups.protocols.UNICAST.down(UNICAST.java:408)
>         at org.jgroups.protocols.pbcast.STABLE.handleStabilityMessage(STABLE.java:622)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:247)
>         at org.jgroups.protocols.UNICAST.up(UNICAST.java:297)
>         at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:823)
>         at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:686)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:271)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> 2009.07.30 16:28:58 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 38d9e5b6-4d65-20b4-7b41-7c6658e928d6 (172 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 09:30:29 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 30 Jul 2009 09:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1703) SLSB pooling
 statistics misleading when using ThreadLocalPool
In-Reply-To: <9489125.1233153944280.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <166361289.1248960629720.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved EJBTHREE-1703.
-------------------------------------

    Fix Version/s: 1.1.11
       Resolution: Done


I've changed maxSize to dynamically adjust according to the number of threads using the ThreadlocalPool. Note that a reentrance means an extra addition to maxSize for the duration of the call. Or in other words: maxSize = createCount - removeCount.
This means that the equation: inUse = maxSize - availableCount will be valid from now on.

Initially maxSize and availableCount are 0 until the first call reaches the SLSB. Then maxSize becomes 1. AvailableCount will become 1 after the call finishes. Off course both values are bogus in relation to the ThreadlocalPool, because in actuality it can create an infinite amount of instances to service reentrant calls and other threads.

Again the real maximum size of the ThreadlocalPool is governed by the amount of threads calling upon the SLSB. If this is an unreasonable large number or the calls are coming from a thread factory instead of a thread pool, then StrictMaxPool must be used instead.

> SLSB pooling statistics misleading when using ThreadLocalPool
> -------------------------------------------------------------
>
>                 Key: EJBTHREE-1703
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1703
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: pool
>    Affects Versions: AS 4.2.3.GA, 1.0.0-GA
>            Reporter: Galder Zamarreno
>            Assignee: Carlo de Wolf
>            Priority: Critical
>             Fix For: 1.1.11
>
>
> SLSB pooling statistics are hugely misleading when using default ThreadLocalPool:
> "The default pooling strategy used by EJB3 SLSBs is a ThreadLocalPool whose maximum is not really 
> quantifiable. The maximum is the maximum number of concurrent threads talking to that EJB3 SLSB 
> that the system can allocate. So, the MaxSize that you see in that JMX view is bogus at least for its 
> current definition of maximum.
> MaxSize - AvailableCount will give you the number of EJB3 SLSBs currently in use, in your case, 0. Again, 
> the meaning of AvailableCount for this pool strategy is not precise.
> CreateCount does represent the number of EJB3 SLSBs that have been created.
> CurrentSize is a bit more complicated to explain. For each thread that uses an EJB3 SLSBs, thread local 
> pool maintains a pool per each thread where there's an instance active in case it's needed again. So, 
> CurrentSize indicates how many of these active instances there are, which assuming that each thread 
> uses only one instance of the bean, matches the number of instances that have been created."
> Example:
> AvailableCount 	int 	R 	30 	MBean Attribute.
> MaxSize 	                int 	R 	30 	MBean Attribute.
> StateString 	        java.lang.String 	R 	Started 	MBean Attribute.
> State 	                int 	R 	3 	MBean Attribute.
> CurrentSize 	        int 	R 	165 	MBean Attribute.
> CreateCount 	        int 	R 	165 	MBean Attribute.
> RemoveCount 	        int 	R 	0 	MBean Attribute.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 09:46:41 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 30 Jul 2009 09:46:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1556) Add
 additional core management notifications
In-Reply-To: <4089038.1237901302475.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <247681520.1248961601750.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned JBMESSAGING-1556:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> Add additional core management notifications
> --------------------------------------------
>
>                 Key: JBMESSAGING-1556
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1556
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> Add additional management notifications for the following events in JBM server:
> 1/ notifications for start/stop of some messaging component: 
> - ACCEPTOR_STARTED / ACCEPTOR_STOPPED 
> - BRIDGE_STARTED / BRIDGE_STOPPED 
> - BROADCAST_GROUP_STARTED / BROADCAST_GROUP_STOPPED 
> - CLUSTER_CONNECTION_STARTED / CLUSTER_CONNECTION_STOPPED 
> - DISCOVERY_GROUP_STARTED / DISCOVERY_GROUP_STOPPED 
> 2/ I was also thinking to add notifications when messages are expired/moved to the dead letter address but I'm not sure these notifications should be enabled by default (they can potentially generate a lot of notifications): 
> EXPIRED_MESSAGE -> when a message is expired 
> MOVED_TO_DEAD_LETTER_ADDRESS -> when a message is moved to the DLA 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 10:00:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 10:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-217)
 ConfigPropertyMetaData has incorrect toString() implementation
Message-ID: <521983232.1248962429302.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

ConfigPropertyMetaData has incorrect toString() implementation
--------------------------------------------------------------

                 Key: JBMETA-217
                 URL: https://jira.jboss.org/jira/browse/JBMETA-217
             Project: JBoss Metadata
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Jesper Pedersen
            Assignee: Jeff Zhang
            Priority: Minor


ConfigPropertyMetaData has an incorrect toString() implementation.

Check if there are other classes that suffers from the same problem.

(Using trunk snapshot)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 10:03:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 10:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-218) Create common base
 class for all JCA 1.6 implementations
Message-ID: <1703984697.1248962609195.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Create common base class for all JCA 1.6 implementations
--------------------------------------------------------

                 Key: JBMETA-218
                 URL: https://jira.jboss.org/jira/browse/JBMETA-218
             Project: JBoss Metadata
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Jesper Pedersen
            Assignee: Jeff Zhang


Create a common base class for all the JCA 1.6 implementations, like

 JCA16Base

which contains the following:

   private boolean metadataComplete;
   private List<String> requiredWorkContexts;


   public boolean isMetadataComplete()
   {
      return metadataComplete;
   }

   @XmlAttribute(required=true)
   public void setMetadataComplete(boolean metadataComplete)
   {
      this.metadataComplete = metadataComplete;
   }

   public List<String> getRequiredWorkContexts()
   {
      return requiredWorkContexts;
   }

   @XmlElement(name = "required-work-context")
   public void setRequiredWorkContexts(List<String> requiredWorkContexts)
   {
      this.requiredWorkContexts = requiredWorkContexts;
   }

This will eliminate the need to type cast to each implementation specific class.

(Using trunk snapshot)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 10:06:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 10:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-133) Create bean
 validation handler class
Message-ID: <1820759790.1248962789155.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Create bean validation handler class
------------------------------------

                 Key: JBJCA-133
                 URL: https://jira.jboss.org/jira/browse/JBJCA-133
             Project: JBoss JCA
          Issue Type: Task
          Components: Standalone
            Reporter: Jesper Pedersen
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha3


Create a class that will handle the bean validation for the JCA 1.6 deployer chain.

The class should be called BeanValidation - located in sjc/src/main/java/org/jboss/jca/sjc/deployers/ra/ for now - and contain the method

  public static void validateObject(Object object) throws ConstraintViolationException


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 10:08:42 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 10:08:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-134) Make bean validation
	optional
Message-ID: <1719684468.1248962922045.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Make bean validation optional
-----------------------------

                 Key: JBJCA-134
                 URL: https://jira.jboss.org/jira/browse/JBJCA-134
             Project: JBoss JCA
          Issue Type: Task
          Components: Standalone
            Reporter: Jesper Pedersen
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha3


Make the bean validation optional in the deployer by making a property called beanValidation in RADeployer.

This property should be true by default, but can be overriding in boot.xml.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 10:12:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 10:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-135) Add support for
 additional bean validation groups
Message-ID: <145547166.1248963149145.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add support for additional bean validation groups
-------------------------------------------------

                 Key: JBJCA-135
                 URL: https://jira.jboss.org/jira/browse/JBJCA-135
             Project: JBoss JCA
          Issue Type: Task
          Components: Standalone
            Reporter: Jesper Pedersen
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha3


Extend our vendor specific deployment descriptor (jboss-ra.xml) with the possibility to add additional bean validation groups.

The jboss-ra.xml should contain functionality to specify f.ex.

 <bean-validation-groups>
   <bean-validation-group>com.mycompany.myproject.bv.Group1</bean-validation-group>
   <bean-validation-group>com.mycompany.myproject.bv.Group2</bean-validation-group>
 </bean-validation-groups>

where each token is a class name.

The metadata part of this task should be handled in JBMETA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 10:24:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 10:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-136) JBoss Logging
	2.2.0.CR1
Message-ID: <797949956.1248963869163.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss Logging 2.2.0.CR1
-----------------------

                 Key: JBJCA-136
                 URL: https://jira.jboss.org/jira/browse/JBJCA-136
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha3




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 10:24:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 10:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-137) JBoss Logging
	Metadata 1.0.0.CR2
Message-ID: <748322675.1248963869227.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss Logging Metadata 1.0.0.CR2
--------------------------------

                 Key: JBJCA-137
                 URL: https://jira.jboss.org/jira/browse/JBJCA-137
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha3




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 10:26:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 10:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-138) JBoss LogManager
	1.1.0.CR6
Message-ID: <325491511.1248963989240.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss LogManager 1.1.0.CR6
--------------------------

                 Key: JBJCA-138
                 URL: https://jira.jboss.org/jira/browse/JBJCA-138
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha3




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 10:44:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 30 Jul 2009 10:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1680) Improving
 the startup of Messaging Post Office service
In-Reply-To: <443833333.1247032268842.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <885834765.1248965069312.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478262#action_12478262 ] 

Howard Gao commented on JBMESSAGING-1680:
-----------------------------------------

I have measured the start-up time of three components of JBM: Server Peer, Messaging Office and GroupMember. The GroupMember is contained in the Messaging Office startup process. Using JBoss 4.2.3.GA, I tested the timing in three cases: single node non clustered with hsql, single node non clustered with mysql, and two nodes clustered with mysql. The result shows


1. The Messaging Office (and GroupMember in clustered case) takes much more longer time to start up in clustered case than in non-clustered case.
In single non-clustered case, Messaging Office takes very little time (e.g. 5ms or 31ms) to start. But in clustered case, it takes more than 6 sec
to start up, of which 98% to 99% are taken by GroupMember. Of the total startup time of GroupMember, around 98% are devoted to the connection of two jgroup channels. And between the two channels, the control channel takes about 30% of the time and the data channel takes about 65%. So if we can start the two channels concurrently, we may save some time.

See the data:

 Total duration: 6107  [GroupMember]
 -----------------------------------------------
 [create-control-channel] : dur 17 ---> 0.28%
 [create-data-channel] : dur 32 ---> 0.52%
 [connect-control-channel] : dur 2011 ---> 32.93%
 [connect-data-channel] : dur 4047 ---> 66.27%
 -----------------------------------------------
 Total duration: 6220  [Messaging PostOffice]
 -----------------------------------------------
 [super-start] : dur 15 ---> 0.24%
 [office-init] : dur 0 ---> 0.0%
 [get-bindings-from-storage] : dur 33 ---> 0.53%
 [groupmember-start] : dur 6118 ---> 98.36%
 [cluster-init] : dur 47 ---> 0.76%
 [load-bindings] : dur 7 ---> 0.11%
 -----------------------------------------------


2. In all cases the ServerPeer start takes a relative short and constant time (around 100ms), see the data:

a) Clustered case -- node0, it takes 99 ms

  Total duration: 99  [Server Peer]
  -----------------------------------------------
  [load-aop-config] : dur 30 ---> 30.3%
  [members-creation] : dur 45 ---> 45.45%
  [start-id-mgrs] : dur 16 ---> 16.16%
  [start-jndi-mappers] : dur 1 ---> 1.01%
  [start-conn-mgrs] : dur 5 ---> 5.05%
  [start-msg-store] : dur 0 ---> 0.0%
  [start-tx-repo] : dur 0 ---> 0.0%
  [loading-tx-repo] : dur 2 ---> 2.02%
  [start-msg-counters] : dur 0 ---> 0.0%
  -----------------------------------------------

b) Non clustered case -- mysql, it takes 101 ms

 Total duration: 101  [Server Peer]
 -----------------------------------------------
 [load-aop-config] : dur 32 ---> 31.68%
 [members-creation] : dur 43 ---> 42.57%
 [start-id-mgrs] : dur 23 ---> 22.77%
 [start-jndi-mappers] : dur 0 ---> 0.0%
 [start-conn-mgrs] : dur 2 ---> 1.98%
 [start-msg-store] : dur 0 ---> 0.0%
 [start-tx-repo] : dur 0 ---> 0.0%
 [loading-tx-repo] : dur 1 ---> 0.99%
 [start-msg-counters] : dur 0 ---> 0.0%
 -----------------------------------------------



> Improving the startup of Messaging Post Office service
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1680
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1680
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Investigating the possibility of starting the two JGroups channels concurrently so that the startup process will be faster.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 11:10:29 2009
From: jira-events at lists.jboss.org (Bulat Nigmatullin (JIRA))
Date: Thu, 30 Jul 2009 11:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1018)
 TP.sendToSingleMember NullPointerException
In-Reply-To: <847418881.1248957389599.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <346113145.1248966629179.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478265#action_12478265 ] 

Bulat Nigmatullin commented on JGRP-1018:
-----------------------------------------

Please, provide exact CVS checkout URL. I'm little confused trying to find out it.

> TP.sendToSingleMember NullPointerException
> ------------------------------------------
>
>                 Key: JGRP-1018
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1018
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.8
>         Environment: Ubuntu Linux 9.04 64-bit
>            Reporter: Bulat Nigmatullin
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> 2009.07.30 16:28:47 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 2a1f5231-474b-aa1c-976d-70f5b32265af (108 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:76)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1436)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1382)
>         at org.jgroups.protocols.pbcast.NAKACK.stable(NAKACK.java:1354)
>         at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:581)
>         at org.jgroups.protocols.UNICAST.down(UNICAST.java:408)
>         at org.jgroups.protocols.pbcast.STABLE.handleStabilityMessage(STABLE.java:622)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:247)
>         at org.jgroups.protocols.UNICAST.up(UNICAST.java:297)
>         at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:823)
>         at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:686)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:271)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> 2009.07.30 16:28:58 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 38d9e5b6-4d65-20b4-7b41-7c6658e928d6 (172 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 11:20:29 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 30 Jul 2009 11:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2099) Example source.
In-Reply-To: <25948784.1243417258146.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1799321103.1248967229194.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen reassigned JBRULES-2099:
---------------------------------------

    Assignee: Kris Verlaenen  (was: Mark Proctor)


> Example source.
> ---------------
>
>                 Key: JBRULES-2099
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2099
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP,eclipse
>            Reporter: gitae yang
>            Assignee: Kris Verlaenen
>             Fix For: 5.0.1.FINAL
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Hi! We are studying Drools 5.0 in order to use..
> But a curious problem has happened, while executeing an example in documentation.
> It is 3.1.3. Defining Processes Using the Process API in drools-5.0-docs\drools-flow\html_single\index.html.
> Actually, 3.1.3.1. Example 1 is working normally, but 3.1.3.2. Example 2 and 3.1.3.3. Example 3 occur error.
> I 'll tell you what we grasp the reason for error, so far.
> When it's working normal, <ActionNode> exists.
> The other way, when it is not working normal, <ActionNode> doesn't exist.
> For example, in case of 3.1.3.2. Example 2
> RuleFlowProcessFactory factory =
>     RuleFlowProcessFactory.createProcess("org.drools.HelloWorldJoinSplit");
> factory
>     // Header
>     .name("HelloWorldJoinSplit")
>     .version("1.0")
>     .packageName("org.drools")
>     // Nodes
>     .startNode(1).name("Start").done()
>     .splitNode(2).name("Split").type(Split.TYPE_AND).done()
>     .actionNode(3).name("Action 1")
>         .action("mvel", "System.out.println(\"Inside Action 1\")").done()                <       -here, NullPointerException occurs.
>     .actionNode(4).name("Action 2")
>         .action("mvel", "System.out.println(\"Inside Action 2\")").done()
>     .joinNode(5).type(Join.TYPE_AND).done()
>     .endNode(6).name("End").done()
>     // Connections
>     .connection(1, 2)
>     .connection(2, 3)
>     .connection(2, 4)
>     .connection(3, 5)
>     .connection(4, 5)
>     .connection(5, 6);
> RuleFlowProcess process = factory.validate().getProcess();
> Please, let me know entire source I can execute this example well.
> Thank you for your consideration.
> I am waiting for you answer.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 11:30:29 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 30 Jul 2009 11:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2099) Example source.
In-Reply-To: <25948784.1243417258146.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <714321818.1248967829184.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478270#action_12478270 ] 

Kris Verlaenen commented on JBRULES-2099:
-----------------------------------------

When executing the code fragment you have provided, I do not see any NullPointerException.
Do you have a sample Java file that can be used to reproduce this?

> Example source.
> ---------------
>
>                 Key: JBRULES-2099
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2099
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP,eclipse
>            Reporter: gitae yang
>            Assignee: Kris Verlaenen
>             Fix For: 5.0.1.FINAL
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Hi! We are studying Drools 5.0 in order to use..
> But a curious problem has happened, while executeing an example in documentation.
> It is 3.1.3. Defining Processes Using the Process API in drools-5.0-docs\drools-flow\html_single\index.html.
> Actually, 3.1.3.1. Example 1 is working normally, but 3.1.3.2. Example 2 and 3.1.3.3. Example 3 occur error.
> I 'll tell you what we grasp the reason for error, so far.
> When it's working normal, <ActionNode> exists.
> The other way, when it is not working normal, <ActionNode> doesn't exist.
> For example, in case of 3.1.3.2. Example 2
> RuleFlowProcessFactory factory =
>     RuleFlowProcessFactory.createProcess("org.drools.HelloWorldJoinSplit");
> factory
>     // Header
>     .name("HelloWorldJoinSplit")
>     .version("1.0")
>     .packageName("org.drools")
>     // Nodes
>     .startNode(1).name("Start").done()
>     .splitNode(2).name("Split").type(Split.TYPE_AND).done()
>     .actionNode(3).name("Action 1")
>         .action("mvel", "System.out.println(\"Inside Action 1\")").done()                <       -here, NullPointerException occurs.
>     .actionNode(4).name("Action 2")
>         .action("mvel", "System.out.println(\"Inside Action 2\")").done()
>     .joinNode(5).type(Join.TYPE_AND).done()
>     .endNode(6).name("End").done()
>     // Connections
>     .connection(1, 2)
>     .connection(2, 3)
>     .connection(2, 4)
>     .connection(3, 5)
>     .connection(4, 5)
>     .connection(5, 6);
> RuleFlowProcess process = factory.validate().getProcess();
> Please, let me know entire source I can execute this example well.
> Thank you for your consideration.
> I am waiting for you answer.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 12:09:40 2009
From: jira-events at lists.jboss.org (Marek Posolda (JIRA))
Date: Thu, 30 Jul 2009 12:09:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2438) Partial refresh
 does not work with HTTPS
Message-ID: <173244925.1248970180853.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Partial refresh does not work with HTTPS
----------------------------------------

                 Key: JBPORTAL-2438
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2438
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.7.2 Final
         Environment: JBoss Portal from 2.7 branch, 
JBoss AS 4.2.3.GA
JDK 1.5 from Sun
            Reporter: Marek Posolda
             Fix For: 2.7.3 Final
         Attachments: server.xml

It seems that partial refresh does not work when trying to access JBoss Portal through HTTPS. The whole page is reloaded during each request on Partial Request Page.
SSL is configured with self-signed certificate (CN = localhost). server.xml is in attachement for entireness but it seems that problem is not in SSL configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 12:09:40 2009
From: jira-events at lists.jboss.org (Marek Posolda (JIRA))
Date: Thu, 30 Jul 2009 12:09:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-2438) Partial refresh
 does not work with HTTPS
In-Reply-To: <173244925.1248970180853.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <96509436.1248970180949.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Posolda updated JBPORTAL-2438:
------------------------------------

    Attachment: server.xml


> Partial refresh does not work with HTTPS
> ----------------------------------------
>
>                 Key: JBPORTAL-2438
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2438
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.7.2 Final
>         Environment: JBoss Portal from 2.7 branch, 
> JBoss AS 4.2.3.GA
> JDK 1.5 from Sun
>            Reporter: Marek Posolda
>             Fix For: 2.7.3 Final
>
>         Attachments: server.xml
>
>
> It seems that partial refresh does not work when trying to access JBoss Portal through HTTPS. The whole page is reloaded during each request on Partial Request Page.
> SSL is configured with self-signed certificate (CN = localhost). server.xml is in attachement for entireness but it seems that problem is not in SSL configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 12:34:29 2009
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Thu, 30 Jul 2009 12:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2221) duplicate
 function in different .drl files of same package silently overridden
Message-ID: <122753373.1248971669312.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

duplicate function in different .drl files of same package silently overridden
------------------------------------------------------------------------------

                 Key: JBRULES-2221
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2221
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler (expert)
    Affects Versions: 5.0.1.FINAL
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor


Given package p and .drl files a.drl and b.drl, both in this package.

If a.drl contains a function foo and b.drl a function foo, then b's function will silently supercede a's function, or vice versa. There is no indication of an error in the return value of kBuilder.getErrors().




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 12:41:29 2009
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Thu, 30 Jul 2009 12:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2222) Rule silently
 discarded if RHS calls an undefined DRL function
Message-ID: <263509633.1248972089469.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Rule silently discarded if RHS calls an undefined DRL function
--------------------------------------------------------------

                 Key: JBRULES-2222
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2222
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 5.0.1.FINAL
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor


If a function bar is called on a RHS of a rule in the same .drl file without being defined in the same .drl file, the .drl is compiled without kBuilder.getErrors() returning an error, and the rule is silently discarded (not firing, although it should). - Note that this error occurred when there was a function bar defined in another .drl file of the same package. 

Eclipse does indicate an error.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 12:41:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 30 Jul 2009 12:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-101) Add a stop() method
 to alias shutdown()
Message-ID: <1782760986.1248972089606.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add a stop() method to alias shutdown()
---------------------------------------

                 Key: JBBOOT-101
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-101
             Project: JBoss Bootstrap
          Issue Type: Feature Request
          Components: impl-base, spi
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger


Some users may be expecting server.stop(), so give it to them

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 12:47:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 30 Jul 2009 12:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-101) Add a stop()
 method to alias shutdown()
In-Reply-To: <1782760986.1248972089606.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <992657703.1248972449951.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-101.
----------------------------------------

    Fix Version/s: impl-base-2.0.0-alpha-4
                   spi-2.0.0-alpha-3
       Resolution: Done


> Add a stop() method to alias shutdown()
> ---------------------------------------
>
>                 Key: JBBOOT-101
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-101
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-base, spi
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: impl-base-2.0.0-alpha-4, spi-2.0.0-alpha-3
>
>
> Some users may be expecting server.stop(), so give it to them

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 12:47:30 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Thu, 30 Jul 2009 12:47:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6833) warnings from
 AbstractManagedObjectPopulator printed when ManagementView.load() is called
In-Reply-To: <6769558.1240600726809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <365633227.1248972450107.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478278#action_12478278 ] 

Ian Springer commented on JBAS-6833:
------------------------------------

>From Scott:

This is an artifact of attempting to get the jndi name before there is a value. We need to simply drop the logging level in the jboss-managed project.


> warnings from AbstractManagedObjectPopulator printed when ManagementView.load() is called
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-6833
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6833
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When I call ManagementView.load() , I see the following warnings in the log. They don't seem to cause any harm, but it would be good to fix whatever the underlying cause is, so they don't freak out users and waste space in the log.
> 14:10:03,459 WARN  [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 14:10:04,318 WARN  [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 14:10:04,334 WARN  [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 14:10:04,662 WARN  [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 12:58:29 2009
From: jira-events at lists.jboss.org (Bill Culp (JIRA))
Date: Thu, 30 Jul 2009 12:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-7137) MDBs dont register
 local-jndi-name when provided in jboss.xml
In-Reply-To: <1347556772.1248932189281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <738616551.1248973109205.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bill Culp reopened JBAS-7137:
-----------------------------



So the assertion being m,ade is that <local-jndi-name> which is in the jboss xsd does not exist, and has never worked.

This is incorrect, it does it exist and it used to work.  Please explain the deprectation process of the defined element

<local-jndi-name> under <message-driven> before rejecting a ticket outright.

> MDBs dont register local-jndi-name when provided in jboss.xml
> -------------------------------------------------------------
>
>                 Key: JBAS-7137
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7137
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: WIndows, Java 1.6 huge fat fast machine with thousands of terabytes
>            Reporter: Bill Culp
>            Assignee: Carlo de Wolf
>
> MDBs do not register a JNDI name at all even when local-jndi-name is specified in the jboss.xml and can only be looked up using jboss.j2ee:jar=foo, name=fooname, service=EJB3.
> Also start stop destroy create methods as provided for EJB beans in JMX are not provided.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 13:56:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 13:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-139) Bean Validation:
 TraversableResolver
Message-ID: <734460311.1248976589210.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Bean Validation: TraversableResolver
------------------------------------

                 Key: JBJCA-139
                 URL: https://jira.jboss.org/jira/browse/JBJCA-139
             Project: JBoss JCA
          Issue Type: Task
          Components: Standalone
            Reporter: Jesper Pedersen
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha3


Implement a JCATraversableResolver class that implements the TraversableResolver interface.

Both methods in the interface must return true.

Configure the ValidatorFactory to use this implementation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 14:22:29 2009
From: jira-events at lists.jboss.org (Brian Ko (JIRA))
Date: Thu, 30 Jul 2009 14:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2439) Anonymous
 "admin" permission on a cms node prevent access from everyone except super
 user
Message-ID: <1200069976.1248978149206.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Anonymous "admin" permission on a cms node prevent access from everyone except super user
-----------------------------------------------------------------------------------------

                 Key: JBPORTAL-2439
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2439
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal CMS
    Affects Versions: 2.7.2 Final
         Environment: Windows XP, mySQL 5
            Reporter: Brian Ko
            Assignee: Sohil Shah


Anonymous "admin" permission on a cms node prevent access from everyone except super user

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 14:53:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 30 Jul 2009 14:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-102) Create distinction
 between SPI and API
Message-ID: <223180563.1248980009144.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Create distinction between SPI and API
--------------------------------------

                 Key: JBBOOT-102
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-102
             Project: JBoss Bootstrap
          Issue Type: Feature Request
          Components: api, api-as, api-mc, impl-as, impl-base, impl-mc, spi, spi-as, spi-mc
    Affects Versions: impl-as-2.0.0-alpha-3, impl-as-2.0.0-alpha-2, spi-as-2.0.0-alpha-3, spi-as-2.0.0-alpha-2 , spi-2.0.0-alpha-2 , impl-mc-2.0.0-alpha-2, impl-base-2.0.0-alpha-3, impl-base-2.0.0-alpha-2
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger


The client view of a server or config should not be leaking out internals required by the implementation itself.  Separate out the SPI to extend from an API, where the API is the client-only view.  The SPI may still be used by consuming projects like AS by casting the runtime type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 14:56:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 30 Jul 2009 14:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-103) Remove all
 IDE-specific metadata files
Message-ID: <831182085.1248980189267.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Remove all IDE-specific metadata files
--------------------------------------

                 Key: JBBOOT-103
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-103
             Project: JBoss Bootstrap
          Issue Type: Task
          Components: api, api-as, api-mc, build, impl-as, impl-base, impl-mc, legacy, main, spi, spi-as, spi-mc, spi-test
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: api-2.0.0-alpha-1, api-mc-2.0.0-alpha-1, impl-base-2.0.0-alpha-4, spi-2.0.0-alpha-3, spi-mc-2.0.0-alpha-2, api-as-2.0.0-alpha-1, spi-as-2.0.0-alpha-4, impl-as-2.0.0-alpha-4


I'm done with keeping IDE-specific stuff in SVN.  Remove 'em all, add svn:ignore for these, and let developers manage their own environments.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 14:58:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 30 Jul 2009 14:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-102) Create distinction
 between SPI and API
In-Reply-To: <223180563.1248980009144.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <825922336.1248980309149.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated JBBOOT-102:
---------------------------------------

        Fix Version/s: api-2.0.0-alpha-1
                       api-mc-2.0.0-alpha-1
                       impl-base-2.0.0-alpha-4
                       spi-2.0.0-alpha-3
                       spi-mc-2.0.0-alpha-2
                       api-as-2.0.0-alpha-1
                       spi-as-2.0.0-alpha-4
                       impl-as-2.0.0-alpha-4
    Affects Version/s:     (was: impl-as-2.0.0-alpha-2)
                           (was: spi-as-2.0.0-alpha-2 )
                           (was: spi-2.0.0-alpha-2 )
                           (was: impl-base-2.0.0-alpha-2)
                           (was: impl-base-2.0.0-alpha-3)
                           (was: spi-as-2.0.0-alpha-3)
                           (was: impl-mc-2.0.0-alpha-2)
                           (was: impl-as-2.0.0-alpha-3)


> Create distinction between SPI and API
> --------------------------------------
>
>                 Key: JBBOOT-102
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-102
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: api, api-as, api-mc, impl-as, impl-base, impl-mc, spi, spi-as, spi-mc
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: api-2.0.0-alpha-1, api-mc-2.0.0-alpha-1, impl-base-2.0.0-alpha-4, spi-2.0.0-alpha-3, spi-mc-2.0.0-alpha-2, api-as-2.0.0-alpha-1, spi-as-2.0.0-alpha-4, impl-as-2.0.0-alpha-4
>
>
> The client view of a server or config should not be leaking out internals required by the implementation itself.  Separate out the SPI to extend from an API, where the API is the client-only view.  The SPI may still be used by consuming projects like AS by casting the runtime type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 15:03:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 30 Jul 2009 15:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-104)
 JBossASBasedServerProvider.getMetadata() should return an immutable view
Message-ID: <1230586940.1248980609118.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBossASBasedServerProvider.getMetadata() should return an immutable view
------------------------------------------------------------------------

                 Key: JBBOOT-104
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-104
             Project: JBoss Bootstrap
          Issue Type: Task
          Components: impl-as
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: impl-as-2.0.0-alpha-4


Get the nod from Scott/Emanuel on the linked forum Thread first to ensure that ProfileService isn't adding anything into the Map, but let's assume this constitutes leaking mutable state from the server to clients, and that's a no-no.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 15:40:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 30 Jul 2009 15:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCL-109) Infinite loop when a
 legit LinkageError occurs
In-Reply-To: <157425770.1247195069114.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1795685449.1248982829238.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBCL-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene updated JBCL-109:
---------------------------------

    Fix Version/s: JBossCL.2.0.6.SP1


> Infinite loop when a legit LinkageError occurs
> ----------------------------------------------
>
>                 Key: JBCL-109
>                 URL: https://jira.jboss.org/jira/browse/JBCL-109
>             Project: JBoss ClassLoader
>          Issue Type: Bug
>          Components: ClassLoader
>            Reporter: Jason T. Greene
>            Assignee: Jason T. Greene
>            Priority: Blocker
>             Fix For: JBossCL.2.0.6.SP1, JBossCL.2.0.7.GA
>
>
> To fix an old JVM issue, linkage errors are treated like a ClassCircularityError. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-6327), an infinite loop results. 
> synchronized int incrementNumCCE()
>  {
>      return numCCE;;
>   }
> This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 15:55:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 15:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6918) "trackByTxn"
 always gets displayed as "false" in the output of the "listStatistics"
 operation for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1955326651.1248983729576.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478309#action_12478309 ] 

Jesper Pedersen commented on JBAS-6918:
---------------------------------------

>From the docs:

# <track-connection-by-tx> - whether the connection should be "locked" to the transaction, returning it to the pool at the end of the transaction; in pre-JBoss-5.x releases the default value for Local connection factories is true and false for XA; since JBoss-5.x the default value is true for both Local and XA and the element is deprecated.
# <interleaving/> - enables interleaving for XA connection factories (added in JBoss-5.x)

The element is deprecated.

Let me know if I should remove it from the template.

> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Jesper Pedersen
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 15:55:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 15:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6918) "trackByTxn" always
 gets displayed as "false" in the output of the "listStatistics" operation
 for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <286974471.1248983729734.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBAS-6918:
----------------------------------

    Assignee: Ian Springer  (was: Jesper Pedersen)


> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Ian Springer
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 16:48:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 30 Jul 2009 16:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-102) Create distinction
 between SPI and API
In-Reply-To: <223180563.1248980009144.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1981761517.1248986909152.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-102.
----------------------------------------

    Resolution: Done


> Create distinction between SPI and API
> --------------------------------------
>
>                 Key: JBBOOT-102
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-102
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: api, api-as, api-mc, impl-as, impl-base, impl-mc, spi, spi-as, spi-mc
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: api-2.0.0-alpha-1, api-mc-2.0.0-alpha-1, impl-base-2.0.0-alpha-4, spi-2.0.0-alpha-3, spi-mc-2.0.0-alpha-2, api-as-2.0.0-alpha-1, spi-as-2.0.0-alpha-4, impl-as-2.0.0-alpha-4
>
>
> The client view of a server or config should not be leaking out internals required by the implementation itself.  Separate out the SPI to extend from an API, where the API is the client-only view.  The SPI may still be used by consuming projects like AS by casting the runtime type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 17:00:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 30 Jul 2009 17:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-103) Remove all
 IDE-specific metadata files
In-Reply-To: <831182085.1248980189267.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1921557446.1248987629284.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-103.
----------------------------------------

    Resolution: Done


> Remove all IDE-specific metadata files
> --------------------------------------
>
>                 Key: JBBOOT-103
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-103
>             Project: JBoss Bootstrap
>          Issue Type: Task
>          Components: api, api-as, api-mc, build, impl-as, impl-base, impl-mc, legacy, main, spi, spi-as, spi-mc, spi-test
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: api-2.0.0-alpha-1, api-mc-2.0.0-alpha-1, impl-base-2.0.0-alpha-4, spi-2.0.0-alpha-3, spi-mc-2.0.0-alpha-2, api-as-2.0.0-alpha-1, spi-as-2.0.0-alpha-4, impl-as-2.0.0-alpha-4
>
>
> I'm done with keeping IDE-specific stuff in SVN.  Remove 'em all, add svn:ignore for these, and let developers manage their own environments.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 17:16:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Thu, 30 Jul 2009 17:16:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6918) "trackByTxn"
 always gets displayed as "false" in the output of the "listStatistics"
 operation for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1181110328.1248988589403.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478320#action_12478320 ] 

Ian Springer commented on JBAS-6918:
------------------------------------

Can you remove the trackByTxn element from the map that is returned by the listStatistics managed operation? It appears the value isn't accurate, since it is always false, even when the track-connection-by-tx managed property is set to true. I think it will only confuse users.


> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Ian Springer
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 17:18:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Thu, 30 Jul 2009 17:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6918) "trackByTxn" always
 gets displayed as "false" in the output of the "listStatistics" operation
 for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1876645012.1248988709262.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer reassigned JBAS-6918:
----------------------------------

    Assignee: Jesper Pedersen  (was: Ian Springer)


> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Jesper Pedersen
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 17:24:29 2009
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Thu, 30 Jul 2009 17:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7139) JmsXAResource not
 calculating isSameRM correctly
Message-ID: <1396028309.1248989069183.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JmsXAResource not calculating isSameRM correctly
------------------------------------------------

                 Key: JBAS-7139
                 URL: https://jira.jboss.org/jira/browse/JBAS-7139
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA service
    Affects Versions: JBossAS-5.1.0.GA, JBossAS-4.2.3.GA
            Reporter: Justin Bertram
            Assignee: Justin Bertram
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


JmsXAResource.isSameRM will never return true if a JmsXAResource is passed to it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 17:35:29 2009
From: jira-events at lists.jboss.org (Jimmy Wilson (JIRA))
Date: Thu, 30 Jul 2009 17:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7140) HA-Singleton
	Injection
Message-ID: <1327201134.1248989729459.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

HA-Singleton Injection
----------------------

                 Key: JBAS-7140
                 URL: https://jira.jboss.org/jira/browse/JBAS-7140
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Clustering, EJB3
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Jimmy Wilson
            Assignee: Brian Stansberry


This is just a feature request to be able to inject EJBs and @Service beans such that if they are deployed via HA-Singleton, injection will work as expected via a transparent, delegating proxy on nodes that aren't collocated with the bean in question.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 30 17:37:29 2009
From: jira-events at lists.jboss.org (David McCullars (JIRA))
Date: Thu, 30 Jul 2009 17:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6549) Investigate
 increased memory requirements and deployment time
In-Reply-To: <5128231.1235670884495.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1472561576.1248989849774.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478325#action_12478325 ] 

David McCullars commented on JBAS-6549:
---------------------------------------

We also are suffering from the memory problems in AS5.0.1, so much so we've switched to IBM's JRE (which seems to help slightly with OOME's).  Even still we have OOME's at least once a day in our production environment.  Has anyone tried AS5.1.0 to see if it's better?

> Investigate increased memory requirements and deployment time
> -------------------------------------------------------------
>
>                 Key: JBAS-6549
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6549
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.0.GA, JBossAS-5.0.1.GA
>            Reporter: Dimitris Andreadis
>            Assignee: Ales Justin
>         Attachments: AS 5_x profiler snapshot.zip
>
>
> A user reported x2 increase in deployment time and x4 increase in memory usage when moving an application from JBoss 4.2 -> 5.x.
> We need to investigate how to improve both the memory usage and the deployment time.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 00:43:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 31 Jul 2009 00:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-104)
 JBossASBasedServerProvider.getMetadata() should return an immutable view
In-Reply-To: <1230586940.1248980609118.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <188377293.1249015409648.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-104.
----------------------------------------

    Resolution: Done


> JBossASBasedServerProvider.getMetadata() should return an immutable view
> ------------------------------------------------------------------------
>
>                 Key: JBBOOT-104
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-104
>             Project: JBoss Bootstrap
>          Issue Type: Task
>          Components: impl-as
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: impl-as-2.0.0-alpha-4
>
>
> Get the nod from Scott/Emanuel on the linked forum Thread first to ensure that ProfileService isn't adding anything into the Map, but let's assume this constitutes leaking mutable state from the server to clients, and that's a no-no.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 02:08:29 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Fri, 31 Jul 2009 02:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7130) Stack trace when
 starting up "all" configuration
In-Reply-To: <1446554410.1248826962724.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1603110312.1249020509482.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478353#action_12478353 ] 

Richard Opalka commented on JBAS-7130:
--------------------------------------

How to workaround this problem using default configuration Stan?

> Stack trace when starting up "all" configuration
> ------------------------------------------------
>
>                 Key: JBAS-7130
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7130
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF, Web (Tomcat) service
>            Reporter: David Lloyd
>            Assignee: Stan Silvert
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> I get the following stack trace when starting up in the "all" configuration:
> 19:19:07,154 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
> 19:19:07,187 WARNING [config] Unable to process deployment descriptor for context '/invoker': java.lang.IllegalArgumentException: InputStream cannot be null
> 	at javax.xml.parsers.SAXParser.parse(SAXParser.java:194)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.scanForFacesServlet(ConfigureListener.java:752)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.<init>(ConfigureListener.java:712)
> 	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:165)
> 	at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:60)
> 	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
> 	at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:462)
> 	at org.jboss.web.deployers.WebModule.startModule(WebModule.java:116)
> 	at org.jboss.web.deployers.WebModule.start(WebModule.java:95)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:207)
> 	at $Proxy38.start(Unknown Source)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:653)
> 	at org.jboss.system.ServiceController.register(ServiceController.java:356)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerRegistrationLifecycleCallback.install(ServiceControllerRegistrationLifecycleCallback.java:104)
> 	at sun.reflect.GeneratedMethodAccessor239.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 02:10:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Jul 2009 02:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1018)
 TP.sendToSingleMember NullPointerException
In-Reply-To: <847418881.1248957389599.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <457400447.1249020629153.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478354#action_12478354 ] 

Bela Ban commented on JGRP-1018:
--------------------------------

cvs -d:pserver:anonymous at javagroups.cvs.sourceforge.net:/cvsroot/javagroups login

cvs -z3 -d:pserver:anonymous at javagroups.cvs.sourceforge.net:/cvsroot/javagroups co -P JGroups

> TP.sendToSingleMember NullPointerException
> ------------------------------------------
>
>                 Key: JGRP-1018
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1018
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.8
>         Environment: Ubuntu Linux 9.04 64-bit
>            Reporter: Bulat Nigmatullin
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> 2009.07.30 16:28:47 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 2a1f5231-474b-aa1c-976d-70f5b32265af (108 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:76)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1436)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1382)
>         at org.jgroups.protocols.pbcast.NAKACK.stable(NAKACK.java:1354)
>         at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:581)
>         at org.jgroups.protocols.UNICAST.down(UNICAST.java:408)
>         at org.jgroups.protocols.pbcast.STABLE.handleStabilityMessage(STABLE.java:622)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:247)
>         at org.jgroups.protocols.UNICAST.up(UNICAST.java:297)
>         at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:823)
>         at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:686)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:271)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> 2009.07.30 16:28:58 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 38d9e5b6-4d65-20b4-7b41-7c6658e928d6 (172 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 02:29:51 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Fri, 31 Jul 2009 02:29:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1695)
 JMSServerControl.createQueue() fails when there are any paged messages for
 the Queue
Message-ID: <1851974409.1249021791965.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JMSServerControl.createQueue() fails when there are any paged messages for the Queue
------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1695
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1695
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0.beta4
         Environment: Windows Vista 32 bit 2GB RAM
            Reporter: Bijith Kumar
            Assignee: Tim Fox


Hi,
I am using JMSServerControl.createQueue() to create queues on the fly (programatically) as discussed in http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157444. This works fine and the API creates the Queue or just binds the queue to JNDI if queue already exists. However, this fails as soon as there are any messages paged in the Queue. i.e. If I am trying to use this API for a Queue which already exists and has some messages paged, subsequent calls to this API fails with following Exception. Test file is attached.

[code]java.lang.Exception: did not receive reply for message org.jboss.messaging.core.client.impl.ClientMessageImpl at 18e613d
	at org.jboss.messaging.core.management.impl.ReplicationOperationInvokerImpl.invoke(ReplicationOperationInvokerImpl.java:115)
	at org.jboss.messaging.core.management.jmx.impl.ReplicationAwareStandardMBeanWrapper.replicationAwareInvoke(ReplicationAwareStandardMBeanWrapper.java:75)
	at org.jboss.messaging.jms.server.management.jmx.impl.ReplicationAwareJMSServerControlWrapper.createQueue(ReplicationAwareJMSServerControlWrapper.java:499)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at com.sun.jmx.mbeanserver.StandardMetaDataImpl.invoke(StandardMetaDataImpl.java:414)
	at javax.management.StandardMBean.invoke(StandardMBean.java:323)
	at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
	at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1410)
	at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81)
	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1247)
	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1343)
	at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:784)
	at sun.reflect.GeneratedMethodAccessor27.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)[/code]


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 02:40:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 31 Jul 2009 02:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6314) Problems using EJB
 + Quartz + Seam
In-Reply-To: <29883538.1229034156614.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1908384151.1249022429348.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478357#action_12478357 ] 

jaikiran pai commented on JBAS-6314:
------------------------------------

This has been identified as a EJB3 issue and will be tracked/fixed  through EJBTHREE-1876. Marking this as an duplicate.


> Problems using EJB + Quartz + Seam
> ----------------------------------
>
>                 Key: JBAS-6314
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6314
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows Vista
>            Reporter: Diego Coronel
>            Assignee: Andrew Lee Rubinger
>   Original Estimate: 0 minutes
>  Remaining Estimate: 0 minutes
>
>  problems using quartz/seam with AS5, it works fine in jboss 4.2.2.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 02:42:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 31 Jul 2009 02:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6314) Problems using EJB
 + Quartz + Seam
In-Reply-To: <29883538.1229034156614.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2021657499.1249022549798.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBAS-6314.
--------------------------------

    Resolution: Duplicate Issue
      Assignee: jaikiran pai  (was: Andrew Lee Rubinger)


> Problems using EJB + Quartz + Seam
> ----------------------------------
>
>                 Key: JBAS-6314
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6314
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows Vista
>            Reporter: Diego Coronel
>            Assignee: jaikiran pai
>   Original Estimate: 0 minutes
>  Remaining Estimate: 0 minutes
>
>  problems using quartz/seam with AS5, it works fine in jboss 4.2.2.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 02:42:30 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Fri, 31 Jul 2009 02:42:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1695)
 JMSServerControl.createQueue() fails when there are any paged messages for
 the Queue
In-Reply-To: <1851974409.1249021791965.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <766573491.1249022550100.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1695:
--------------------------------------

    Attachment: Sender.java


Test

> JMSServerControl.createQueue() fails when there are any paged messages for the Queue
> ------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1695
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1695
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta4
>         Environment: Windows Vista 32 bit 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>         Attachments: Sender.java
>
>
> Hi,
> I am using JMSServerControl.createQueue() to create queues on the fly (programatically) as discussed in http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157444. This works fine and the API creates the Queue or just binds the queue to JNDI if queue already exists. However, this fails as soon as there are any messages paged in the Queue. i.e. If I am trying to use this API for a Queue which already exists and has some messages paged, subsequent calls to this API fails with following Exception. Test file is attached.
> [code]java.lang.Exception: did not receive reply for message org.jboss.messaging.core.client.impl.ClientMessageImpl at 18e613d
> 	at org.jboss.messaging.core.management.impl.ReplicationOperationInvokerImpl.invoke(ReplicationOperationInvokerImpl.java:115)
> 	at org.jboss.messaging.core.management.jmx.impl.ReplicationAwareStandardMBeanWrapper.replicationAwareInvoke(ReplicationAwareStandardMBeanWrapper.java:75)
> 	at org.jboss.messaging.jms.server.management.jmx.impl.ReplicationAwareJMSServerControlWrapper.createQueue(ReplicationAwareJMSServerControlWrapper.java:499)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at com.sun.jmx.mbeanserver.StandardMetaDataImpl.invoke(StandardMetaDataImpl.java:414)
> 	at javax.management.StandardMBean.invoke(StandardMBean.java:323)
> 	at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
> 	at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
> 	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1410)
> 	at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81)
> 	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1247)
> 	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1343)
> 	at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:784)
> 	at sun.reflect.GeneratedMethodAccessor27.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)[/code]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 02:49:41 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Fri, 31 Jul 2009 02:49:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1695)
 JMSServerControl.createQueue() fails when there are any paged messages for
 the Queue
In-Reply-To: <1851974409.1249021791965.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <241175632.1249022981350.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478359#action_12478359 ] 

Bijith Kumar commented on JBMESSAGING-1695:
-------------------------------------------

To reproduce the issue, just run the attached Java file 3 times (or more if your Queue memory is large). My Queue memory settings are as follows which can hold apx 23,745 messages


	          <global-page-size>10485760</global-page-size>
	          <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 



> JMSServerControl.createQueue() fails when there are any paged messages for the Queue
> ------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1695
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1695
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta4
>         Environment: Windows Vista 32 bit 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>         Attachments: Sender.java
>
>
> Hi,
> I am using JMSServerControl.createQueue() to create queues on the fly (programatically) as discussed in http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157444. This works fine and the API creates the Queue or just binds the queue to JNDI if queue already exists. However, this fails as soon as there are any messages paged in the Queue. i.e. If I am trying to use this API for a Queue which already exists and has some messages paged, subsequent calls to this API fails with following Exception. Test file is attached.
> [code]java.lang.Exception: did not receive reply for message org.jboss.messaging.core.client.impl.ClientMessageImpl at 18e613d
> 	at org.jboss.messaging.core.management.impl.ReplicationOperationInvokerImpl.invoke(ReplicationOperationInvokerImpl.java:115)
> 	at org.jboss.messaging.core.management.jmx.impl.ReplicationAwareStandardMBeanWrapper.replicationAwareInvoke(ReplicationAwareStandardMBeanWrapper.java:75)
> 	at org.jboss.messaging.jms.server.management.jmx.impl.ReplicationAwareJMSServerControlWrapper.createQueue(ReplicationAwareJMSServerControlWrapper.java:499)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at com.sun.jmx.mbeanserver.StandardMetaDataImpl.invoke(StandardMetaDataImpl.java:414)
> 	at javax.management.StandardMBean.invoke(StandardMBean.java:323)
> 	at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
> 	at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
> 	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1410)
> 	at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81)
> 	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1247)
> 	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1343)
> 	at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:784)
> 	at sun.reflect.GeneratedMethodAccessor27.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)[/code]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 03:57:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 31 Jul 2009 03:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1695)
 JMSServerControl.createQueue() fails when there are any paged messages for
 the Queue
In-Reply-To: <1851974409.1249021791965.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1613602223.1249027049373.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned JBMESSAGING-1695:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> JMSServerControl.createQueue() fails when there are any paged messages for the Queue
> ------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1695
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1695
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta4
>         Environment: Windows Vista 32 bit 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Jeff Mesnil
>         Attachments: Sender.java
>
>
> Hi,
> I am using JMSServerControl.createQueue() to create queues on the fly (programatically) as discussed in http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157444. This works fine and the API creates the Queue or just binds the queue to JNDI if queue already exists. However, this fails as soon as there are any messages paged in the Queue. i.e. If I am trying to use this API for a Queue which already exists and has some messages paged, subsequent calls to this API fails with following Exception. Test file is attached.
> [code]java.lang.Exception: did not receive reply for message org.jboss.messaging.core.client.impl.ClientMessageImpl at 18e613d
> 	at org.jboss.messaging.core.management.impl.ReplicationOperationInvokerImpl.invoke(ReplicationOperationInvokerImpl.java:115)
> 	at org.jboss.messaging.core.management.jmx.impl.ReplicationAwareStandardMBeanWrapper.replicationAwareInvoke(ReplicationAwareStandardMBeanWrapper.java:75)
> 	at org.jboss.messaging.jms.server.management.jmx.impl.ReplicationAwareJMSServerControlWrapper.createQueue(ReplicationAwareJMSServerControlWrapper.java:499)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at com.sun.jmx.mbeanserver.StandardMetaDataImpl.invoke(StandardMetaDataImpl.java:414)
> 	at javax.management.StandardMBean.invoke(StandardMBean.java:323)
> 	at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
> 	at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
> 	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1410)
> 	at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81)
> 	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1247)
> 	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1343)
> 	at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:784)
> 	at sun.reflect.GeneratedMethodAccessor27.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)[/code]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 04:38:29 2009
From: jira-events at lists.jboss.org (Assen Todorov (JIRA))
Date: Fri, 31 Jul 2009 04:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2223)
 ArrayIndexOutOfBoundsException in AbstractRuleBase.getStatefulSessions()
Message-ID: <14379227.1249029509459.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

ArrayIndexOutOfBoundsException in AbstractRuleBase.getStatefulSessions()
------------------------------------------------------------------------

                 Key: JBRULES-2223
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2223
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 4.0.7
            Reporter: Assen Todorov
            Assignee: Mark Proctor


The following exception is thrown on a multithreaded application, based on Terracotta & JBoss Drools (4.0.7).

{code}
java.lang.ArrayIndexOutOfBoundsException: 0
        at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:152)
        at org.drools.common.AbstractRuleBase.getStatefulSessions(AbstractRuleBase.java:724)
        .......
{code}

The code :

{code}
   /**
    * Creates a new rule base if necesarry.
    * @param aRuleSet the rule set for the new rule base.
    * @throws RuleConversionException if the rule engine has a problem with rule set compilation and loading.
    */
   private void createRuleBase(final RuleSet aRuleSet) throws RuleConversionException
   {
      Check.notNull(aRuleSet, "aRuleSet");
      final String code = aRuleSet.getCode();
      Check.notNull(code, "aRuleSet.getCode()");
      Check.notEmpty(code, "aRuleSet.getCode()");

      final ECRC ecrc = new ECRC();
      ecrc.update(code);
      final long crc = ecrc.getValue();

      synchronized(ruleBaseCache)
      {
         ruleBase = ruleBaseCache.get(crc);
         if(ruleBase == null)
         {
            ruleBase = loadRuleBaseFromCode(code);
            ruleBaseCache.put(crc, ruleBase);
         }
         else {
            // rulebase already exist
            final StatefulSession[] sessions = ruleBase.getStatefulSessions();
            if(sessions.length > 0) {
               // old sessions (working memories exist)
               for(StatefulSession session: sessions) {
                  // clear the working memory
                  session.dispose();
               }
            }
         }
      }
   }
{code}

The class where this method is defined, is declared as _instrumented-classes_  in the Terracotta configuration.

Hope this helps !

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 04:40:29 2009
From: jira-events at lists.jboss.org (Assen Todorov (JIRA))
Date: Fri, 31 Jul 2009 04:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2223)
 ArrayIndexOutOfBoundsException in AbstractRuleBase.getStatefulSessions()
In-Reply-To: <14379227.1249029509459.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <185046907.1249029629194.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Assen Todorov updated JBRULES-2223:
-----------------------------------

    Description: 
The following exception is thrown on a clustered application, based on Terracotta & JBoss Drools (4.0.7).

{code}
java.lang.ArrayIndexOutOfBoundsException: 0
        at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:152)
        at org.drools.common.AbstractRuleBase.getStatefulSessions(AbstractRuleBase.java:724)
        .......
{code}

The code :

{code}
   /**
    * Creates a new rule base if necesarry.
    * @param aRuleSet the rule set for the new rule base.
    * @throws RuleConversionException if the rule engine has a problem with rule set compilation and loading.
    */
   private void createRuleBase(final RuleSet aRuleSet) throws RuleConversionException
   {
      Check.notNull(aRuleSet, "aRuleSet");
      final String code = aRuleSet.getCode();
      Check.notNull(code, "aRuleSet.getCode()");
      Check.notEmpty(code, "aRuleSet.getCode()");

      final ECRC ecrc = new ECRC();
      ecrc.update(code);
      final long crc = ecrc.getValue();

      synchronized(ruleBaseCache)
      {
         ruleBase = ruleBaseCache.get(crc);
         if(ruleBase == null)
         {
            ruleBase = loadRuleBaseFromCode(code);
            ruleBaseCache.put(crc, ruleBase);
         }
         else {
            // rulebase already exist
            final StatefulSession[] sessions = ruleBase.getStatefulSessions();
            if(sessions.length > 0) {
               // old sessions (working memories exist)
               for(StatefulSession session: sessions) {
                  // clear the working memory
                  session.dispose();
               }
            }
         }
      }
   }
{code}

The class where this method is defined, is declared as _instrumented-classes_  in the Terracotta configuration.

Hope this helps !

  was:
The following exception is thrown on a multithreaded application, based on Terracotta & JBoss Drools (4.0.7).

{code}
java.lang.ArrayIndexOutOfBoundsException: 0
        at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:152)
        at org.drools.common.AbstractRuleBase.getStatefulSessions(AbstractRuleBase.java:724)
        .......
{code}

The code :

{code}
   /**
    * Creates a new rule base if necesarry.
    * @param aRuleSet the rule set for the new rule base.
    * @throws RuleConversionException if the rule engine has a problem with rule set compilation and loading.
    */
   private void createRuleBase(final RuleSet aRuleSet) throws RuleConversionException
   {
      Check.notNull(aRuleSet, "aRuleSet");
      final String code = aRuleSet.getCode();
      Check.notNull(code, "aRuleSet.getCode()");
      Check.notEmpty(code, "aRuleSet.getCode()");

      final ECRC ecrc = new ECRC();
      ecrc.update(code);
      final long crc = ecrc.getValue();

      synchronized(ruleBaseCache)
      {
         ruleBase = ruleBaseCache.get(crc);
         if(ruleBase == null)
         {
            ruleBase = loadRuleBaseFromCode(code);
            ruleBaseCache.put(crc, ruleBase);
         }
         else {
            // rulebase already exist
            final StatefulSession[] sessions = ruleBase.getStatefulSessions();
            if(sessions.length > 0) {
               // old sessions (working memories exist)
               for(StatefulSession session: sessions) {
                  // clear the working memory
                  session.dispose();
               }
            }
         }
      }
   }
{code}

The class where this method is defined, is declared as _instrumented-classes_  in the Terracotta configuration.

Hope this helps !



> ArrayIndexOutOfBoundsException in AbstractRuleBase.getStatefulSessions()
> ------------------------------------------------------------------------
>
>                 Key: JBRULES-2223
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2223
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0.7
>            Reporter: Assen Todorov
>            Assignee: Mark Proctor
>
> The following exception is thrown on a clustered application, based on Terracotta & JBoss Drools (4.0.7).
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 0
>         at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:152)
>         at org.drools.common.AbstractRuleBase.getStatefulSessions(AbstractRuleBase.java:724)
>         .......
> {code}
> The code :
> {code}
>    /**
>     * Creates a new rule base if necesarry.
>     * @param aRuleSet the rule set for the new rule base.
>     * @throws RuleConversionException if the rule engine has a problem with rule set compilation and loading.
>     */
>    private void createRuleBase(final RuleSet aRuleSet) throws RuleConversionException
>    {
>       Check.notNull(aRuleSet, "aRuleSet");
>       final String code = aRuleSet.getCode();
>       Check.notNull(code, "aRuleSet.getCode()");
>       Check.notEmpty(code, "aRuleSet.getCode()");
>       final ECRC ecrc = new ECRC();
>       ecrc.update(code);
>       final long crc = ecrc.getValue();
>       synchronized(ruleBaseCache)
>       {
>          ruleBase = ruleBaseCache.get(crc);
>          if(ruleBase == null)
>          {
>             ruleBase = loadRuleBaseFromCode(code);
>             ruleBaseCache.put(crc, ruleBase);
>          }
>          else {
>             // rulebase already exist
>             final StatefulSession[] sessions = ruleBase.getStatefulSessions();
>             if(sessions.length > 0) {
>                // old sessions (working memories exist)
>                for(StatefulSession session: sessions) {
>                   // clear the working memory
>                   session.dispose();
>                }
>             }
>          }
>       }
>    }
> {code}
> The class where this method is defined, is declared as _instrumented-classes_  in the Terracotta configuration.
> Hope this helps !

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 04:43:29 2009
From: jira-events at lists.jboss.org (Tej jbpm (JIRA))
Date: Fri, 31 Jul 2009 04:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-368) Unable to delete
	process instance
Message-ID: <535972591.1249029809145.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Unable to delete process instance 
----------------------------------

                 Key: GPD-368
                 URL: https://jira.jboss.org/jira/browse/GPD-368
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM jPDL Designer 3.2
         Environment: Eclipse 3.4.2, JBPM JPDL 3.2.1
            Reporter: Tej jbpm
            Assignee: Koen Aers


Whenever I have a process state node in my process definition ..I am unable to delete the process definition.
This is the error message:
2009-07-31 09:34:13,009 [http-80-Processor25]  WARN (JDBCExceptionReporter.java:77) - SQL Error: 1451, SQLState: 23000

2009-07-31 09:34:13,010 [http-80-Processor25] ERROR (JDBCExceptionReporter.java:78) - Cannot delete or update a parent row: a foreign key constraint fails (`bapsr`.`jbpm_node`, CONSTRAINT `fk_procst_sbprcdef` FOREIGN KEY (`subprocessdefinition_`) REFERENCES `jbpm_processdefinition` (`id_`))

2009-07-31 09:34:13,010 [http-80-Processor25] ERROR (AbstractFlushingEventListener.java:301) - 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:253)

	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:235)

	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:144)

	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.jbpm.jsf.core.action.DeleteActionListener.handleAction(DeleteActionListener.java:50)

	at org.jbpm.jsf.core.impl.JbpmActionListenerWrapper.processAction(JbpmActionListenerWrapper.java:82)

	at javax.faces.event.ActionEvent.processListener(ActionEvent.java:77)

	at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:758)

	at javax.faces.component.UICommand.broadcast(UICommand.java:368)

	at org.ajax4jsf.component.AjaxViewRoot.processEvents(AjaxViewRoot.java:186)

	at org.ajax4jsf.component.AjaxViewRoot.broadcastEvents(AjaxViewRoot.java:164)

	at org.ajax4jsf.component.AjaxViewRoot.processApplication(AjaxViewRoot.java:352)

	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:97)

	at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)

	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)

	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)

	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)

	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)

	at com.njw.session.BASessionExpiryFilter.doFilter(BASessionExpiryFilter.java:43)

	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)

	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)

	at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)

	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)

	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.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.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)

	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)

	at java.lang.Thread.run(Thread.java:595)

Caused by: java.sql.BatchUpdateException: Cannot delete or update a parent row: a foreign key constraint fails (`bapsr`.`jbpm_node`, CONSTRAINT `fk_procst_sbprcdef` FOREIGN KEY (`subprocessdefinition_`) REFERENCES `jbpm_processdefinition` (`id_`))

	at com.mysql.jdbc.ServerPreparedStatement.executeBatch(ServerPreparedStatement.java:665)

	at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:48)

	at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:246)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 04:56:29 2009
From: jira-events at lists.jboss.org (Assen Todorov (JIRA))
Date: Fri, 31 Jul 2009 04:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2223)
 ArrayIndexOutOfBoundsException in AbstractRuleBase.getStatefulSessions()
In-Reply-To: <14379227.1249029509459.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1334691220.1249030589213.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Assen Todorov updated JBRULES-2223:
-----------------------------------

    Description: 
The following exception was thrown on a clustered application, based on Terracotta & JBoss Drools (4.0.7).

{code}
java.lang.ArrayIndexOutOfBoundsException: 0
        at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:152)
        at org.drools.common.AbstractRuleBase.getStatefulSessions(AbstractRuleBase.java:724)
        .......
{code}

The code :

{code}
   /**
    * Creates a new rule base if necesarry.
    * @param aRuleSet the rule set for the new rule base.
    * @throws RuleConversionException if the rule engine has a problem with rule set compilation and loading.
    */
   private void createRuleBase(final RuleSet aRuleSet) throws RuleConversionException
   {
      Check.notNull(aRuleSet, "aRuleSet");
      final String code = aRuleSet.getCode();
      Check.notNull(code, "aRuleSet.getCode()");
      Check.notEmpty(code, "aRuleSet.getCode()");

      final ECRC ecrc = new ECRC();
      ecrc.update(code);
      final long crc = ecrc.getValue();

      synchronized(ruleBaseCache)
      {
         ruleBase = ruleBaseCache.get(crc);
         if(ruleBase == null)
         {
            ruleBase = loadRuleBaseFromCode(code);
            ruleBaseCache.put(crc, ruleBase);
         }
         else {
            // rulebase already exist
            final StatefulSession[] sessions = ruleBase.getStatefulSessions();
            if(sessions.length > 0) {
               // old sessions (working memories exist)
               for(StatefulSession session: sessions) {
                  // clear the working memory
                  session.dispose();
               }
            }
         }
      }
   }
{code}

The class where this method is defined, is declared as _instrumented-classes_  in the Terracotta configuration.

Hope this helps !

  was:
The following exception is thrown on a clustered application, based on Terracotta & JBoss Drools (4.0.7).

{code}
java.lang.ArrayIndexOutOfBoundsException: 0
        at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:152)
        at org.drools.common.AbstractRuleBase.getStatefulSessions(AbstractRuleBase.java:724)
        .......
{code}

The code :

{code}
   /**
    * Creates a new rule base if necesarry.
    * @param aRuleSet the rule set for the new rule base.
    * @throws RuleConversionException if the rule engine has a problem with rule set compilation and loading.
    */
   private void createRuleBase(final RuleSet aRuleSet) throws RuleConversionException
   {
      Check.notNull(aRuleSet, "aRuleSet");
      final String code = aRuleSet.getCode();
      Check.notNull(code, "aRuleSet.getCode()");
      Check.notEmpty(code, "aRuleSet.getCode()");

      final ECRC ecrc = new ECRC();
      ecrc.update(code);
      final long crc = ecrc.getValue();

      synchronized(ruleBaseCache)
      {
         ruleBase = ruleBaseCache.get(crc);
         if(ruleBase == null)
         {
            ruleBase = loadRuleBaseFromCode(code);
            ruleBaseCache.put(crc, ruleBase);
         }
         else {
            // rulebase already exist
            final StatefulSession[] sessions = ruleBase.getStatefulSessions();
            if(sessions.length > 0) {
               // old sessions (working memories exist)
               for(StatefulSession session: sessions) {
                  // clear the working memory
                  session.dispose();
               }
            }
         }
      }
   }
{code}

The class where this method is defined, is declared as _instrumented-classes_  in the Terracotta configuration.

Hope this helps !



> ArrayIndexOutOfBoundsException in AbstractRuleBase.getStatefulSessions()
> ------------------------------------------------------------------------
>
>                 Key: JBRULES-2223
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2223
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0.7
>            Reporter: Assen Todorov
>            Assignee: Mark Proctor
>
> The following exception was thrown on a clustered application, based on Terracotta & JBoss Drools (4.0.7).
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 0
>         at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:152)
>         at org.drools.common.AbstractRuleBase.getStatefulSessions(AbstractRuleBase.java:724)
>         .......
> {code}
> The code :
> {code}
>    /**
>     * Creates a new rule base if necesarry.
>     * @param aRuleSet the rule set for the new rule base.
>     * @throws RuleConversionException if the rule engine has a problem with rule set compilation and loading.
>     */
>    private void createRuleBase(final RuleSet aRuleSet) throws RuleConversionException
>    {
>       Check.notNull(aRuleSet, "aRuleSet");
>       final String code = aRuleSet.getCode();
>       Check.notNull(code, "aRuleSet.getCode()");
>       Check.notEmpty(code, "aRuleSet.getCode()");
>       final ECRC ecrc = new ECRC();
>       ecrc.update(code);
>       final long crc = ecrc.getValue();
>       synchronized(ruleBaseCache)
>       {
>          ruleBase = ruleBaseCache.get(crc);
>          if(ruleBase == null)
>          {
>             ruleBase = loadRuleBaseFromCode(code);
>             ruleBaseCache.put(crc, ruleBase);
>          }
>          else {
>             // rulebase already exist
>             final StatefulSession[] sessions = ruleBase.getStatefulSessions();
>             if(sessions.length > 0) {
>                // old sessions (working memories exist)
>                for(StatefulSession session: sessions) {
>                   // clear the working memory
>                   session.dispose();
>                }
>             }
>          }
>       }
>    }
> {code}
> The class where this method is defined, is declared as _instrumented-classes_  in the Terracotta configuration.
> Hope this helps !

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 04:56:29 2009
From: jira-events at lists.jboss.org (Bulat Nigmatullin (JIRA))
Date: Fri, 31 Jul 2009 04:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1018)
 TP.sendToSingleMember NullPointerException
In-Reply-To: <847418881.1248957389599.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <246212737.1249030589315.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478362#action_12478362 ] 

Bulat Nigmatullin commented on JGRP-1018:
-----------------------------------------

I've checked out jgroups. You say there shouldn't to be sendToSingleMember() method, but it is still there and produces the same error. May be you gave me wrong CVS URL?

> TP.sendToSingleMember NullPointerException
> ------------------------------------------
>
>                 Key: JGRP-1018
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1018
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.8
>         Environment: Ubuntu Linux 9.04 64-bit
>            Reporter: Bulat Nigmatullin
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> 2009.07.30 16:28:47 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 2a1f5231-474b-aa1c-976d-70f5b32265af (108 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:76)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1436)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1382)
>         at org.jgroups.protocols.pbcast.NAKACK.stable(NAKACK.java:1354)
>         at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:581)
>         at org.jgroups.protocols.UNICAST.down(UNICAST.java:408)
>         at org.jgroups.protocols.pbcast.STABLE.handleStabilityMessage(STABLE.java:622)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:247)
>         at org.jgroups.protocols.UNICAST.up(UNICAST.java:297)
>         at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:823)
>         at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:686)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:271)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> 2009.07.30 16:28:58 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 38d9e5b6-4d65-20b4-7b41-7c6658e928d6 (172 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 05:03:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 31 Jul 2009 05:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1680) Improving
 the startup of Messaging Post Office service
In-Reply-To: <443833333.1247032268842.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1051517036.1249031009240.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478364#action_12478364 ] 

Howard Gao commented on JBMESSAGING-1680:
-----------------------------------------


By kicking off another thread to start the data channel in GroupMember, we can save about 2 sec. See data:

 Total duration: 4040  [GroupMember]
 -----------------------------------------------
 [create-control-channel] : dur 15 ---> 0.37%
 [kickoff-data-thread] : dur 23 ---> 0.57%
 [connect-control-channel] : dur 2008 ---> 49.7%
 [waiting-data-channel] : dur 1994 ---> 49.36%
 -----------------------------------------------
 Total duration: 4120  [Messaging PostOffice]
 -----------------------------------------------
 [super-start] : dur 2 ---> 0.05%
 [office-init] : dur 0 ---> 0.0%
 [get-bindings-from-storage] : dur 24 ---> 0.58%
 [groupmember-start] : dur 4049 ---> 98.28%
 [cluster-init] : dur 37 ---> 0.9%
 [load-bindings] : dur 8 ---> 0.19%
 -----------------------------------------------


> Improving the startup of Messaging Post Office service
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1680
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1680
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Investigating the possibility of starting the two JGroups channels concurrently so that the startup process will be faster.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 05:19:29 2009
From: jira-events at lists.jboss.org (Bulat Nigmatullin (JIRA))
Date: Fri, 31 Jul 2009 05:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1018)
 TP.sendToSingleMember NullPointerException
In-Reply-To: <847418881.1248957389599.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <458173589.1249031969560.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478365#action_12478365 ] 

Bulat Nigmatullin commented on JGRP-1018:
-----------------------------------------

May this problem be linked to 'could not flush the cluster for state retrieval' problem on other node joining to the cluster?

> TP.sendToSingleMember NullPointerException
> ------------------------------------------
>
>                 Key: JGRP-1018
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1018
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.8
>         Environment: Ubuntu Linux 9.04 64-bit
>            Reporter: Bulat Nigmatullin
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> 2009.07.30 16:28:47 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 2a1f5231-474b-aa1c-976d-70f5b32265af (108 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:76)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1436)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1382)
>         at org.jgroups.protocols.pbcast.NAKACK.stable(NAKACK.java:1354)
>         at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:581)
>         at org.jgroups.protocols.UNICAST.down(UNICAST.java:408)
>         at org.jgroups.protocols.pbcast.STABLE.handleStabilityMessage(STABLE.java:622)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:247)
>         at org.jgroups.protocols.UNICAST.up(UNICAST.java:297)
>         at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:823)
>         at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:686)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:271)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> 2009.07.30 16:28:58 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 38d9e5b6-4d65-20b4-7b41-7c6658e928d6 (172 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 05:27:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Fri, 31 Jul 2009 05:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-368) Unable to delete
	process instance
In-Reply-To: <535972591.1249029809145.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1979941882.1249032449305.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-368.
---------------------------

    Resolution: Rejected


This problem is not related to the graphical designer. Please use the JBPM project in JIRA if it is a problem related to the engine.

> Unable to delete process instance 
> ----------------------------------
>
>                 Key: GPD-368
>                 URL: https://jira.jboss.org/jira/browse/GPD-368
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM jPDL Designer 3.2
>         Environment: Eclipse 3.4.2, JBPM JPDL 3.2.1
>            Reporter: Tej jbpm
>            Assignee: Koen Aers
>
> Whenever I have a process state node in my process definition ..I am unable to delete the process definition.
> This is the error message:
> 2009-07-31 09:34:13,009 [http-80-Processor25]  WARN (JDBCExceptionReporter.java:77) - SQL Error: 1451, SQLState: 23000
> 2009-07-31 09:34:13,010 [http-80-Processor25] ERROR (JDBCExceptionReporter.java:78) - Cannot delete or update a parent row: a foreign key constraint fails (`bapsr`.`jbpm_node`, CONSTRAINT `fk_procst_sbprcdef` FOREIGN KEY (`subprocessdefinition_`) REFERENCES `jbpm_processdefinition` (`id_`))
> 2009-07-31 09:34:13,010 [http-80-Processor25] ERROR (AbstractFlushingEventListener.java:301) - 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:253)
> 	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:235)
> 	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:144)
> 	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.jbpm.jsf.core.action.DeleteActionListener.handleAction(DeleteActionListener.java:50)
> 	at org.jbpm.jsf.core.impl.JbpmActionListenerWrapper.processAction(JbpmActionListenerWrapper.java:82)
> 	at javax.faces.event.ActionEvent.processListener(ActionEvent.java:77)
> 	at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:758)
> 	at javax.faces.component.UICommand.broadcast(UICommand.java:368)
> 	at org.ajax4jsf.component.AjaxViewRoot.processEvents(AjaxViewRoot.java:186)
> 	at org.ajax4jsf.component.AjaxViewRoot.broadcastEvents(AjaxViewRoot.java:164)
> 	at org.ajax4jsf.component.AjaxViewRoot.processApplication(AjaxViewRoot.java:352)
> 	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:97)
> 	at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at com.njw.session.BASessionExpiryFilter.doFilter(BASessionExpiryFilter.java:43)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
> 	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
> 	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.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.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> 	at java.lang.Thread.run(Thread.java:595)
> Caused by: java.sql.BatchUpdateException: Cannot delete or update a parent row: a foreign key constraint fails (`bapsr`.`jbpm_node`, CONSTRAINT `fk_procst_sbprcdef` FOREIGN KEY (`subprocessdefinition_`) REFERENCES `jbpm_processdefinition` (`id_`))
> 	at com.mysql.jdbc.ServerPreparedStatement.executeBatch(ServerPreparedStatement.java:665)
> 	at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:48)
> 	at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:246)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 05:32:46 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Jul 2009 05:32:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1018)
 TP.sendToSingleMember NullPointerException
In-Reply-To: <847418881.1248957389599.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1503146293.1249032766049.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478367#action_12478367 ] 

Bela Ban commented on JGRP-1018:
--------------------------------

OK, I need the stack trace for CVS head, or else I cannot match the line numbers, please attach it to this case (lastest CVS)

> TP.sendToSingleMember NullPointerException
> ------------------------------------------
>
>                 Key: JGRP-1018
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1018
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.8
>         Environment: Ubuntu Linux 9.04 64-bit
>            Reporter: Bulat Nigmatullin
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> 2009.07.30 16:28:47 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 2a1f5231-474b-aa1c-976d-70f5b32265af (108 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:76)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1436)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1382)
>         at org.jgroups.protocols.pbcast.NAKACK.stable(NAKACK.java:1354)
>         at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:581)
>         at org.jgroups.protocols.UNICAST.down(UNICAST.java:408)
>         at org.jgroups.protocols.pbcast.STABLE.handleStabilityMessage(STABLE.java:622)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:247)
>         at org.jgroups.protocols.UNICAST.up(UNICAST.java:297)
>         at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:823)
>         at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:686)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:271)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> 2009.07.30 16:28:58 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 38d9e5b6-4d65-20b4-7b41-7c6658e928d6 (172 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 05:42:29 2009
From: jira-events at lists.jboss.org (Bulat Nigmatullin (JIRA))
Date: Fri, 31 Jul 2009 05:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1018)
 TP.sendToSingleMember NullPointerException
In-Reply-To: <847418881.1248957389599.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <427966290.1249033349498.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478369#action_12478369 ] 

Bulat Nigmatullin commented on JGRP-1018:
-----------------------------------------

2009.07.31 13:15:05 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 177de77e-d5af-e6db-d4f1-8b9b3cb4d8ff (172 bytes)
java.lang.NullPointerException
        at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1081)
        at org.jgroups.protocols.TP.doSend(TP.java:1069)
        at org.jgroups.protocols.TP.send(TP.java:1052)
        at org.jgroups.protocols.TP.down(TP.java:913)
        at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1912)
        at org.jgroups.protocols.Discovery.down(Discovery.java:406)
        at org.jgroups.protocols.TCPPING.down(TCPPING.java:148)
        at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
        at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
        at org.jgroups.protocols.FD.down(FD.java:300)
        at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
        at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
        at org.jgroups.protocols.FD.up(FD.java:265)
        at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
        at org.jgroups.stack.Protocol.up(Protocol.java:336)
        at org.jgroups.protocols.Discovery.up(Discovery.java:234)
        at org.jgroups.stack.Protocol.up(Protocol.java:336)
        at org.jgroups.protocols.TP.passMessageUp(TP.java:964)
        at org.jgroups.protocols.TP.access$100(TP.java:53)
        at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1478)
        at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1455)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)


> TP.sendToSingleMember NullPointerException
> ------------------------------------------
>
>                 Key: JGRP-1018
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1018
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.8
>         Environment: Ubuntu Linux 9.04 64-bit
>            Reporter: Bulat Nigmatullin
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> 2009.07.30 16:28:47 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 2a1f5231-474b-aa1c-976d-70f5b32265af (108 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:76)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1436)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1382)
>         at org.jgroups.protocols.pbcast.NAKACK.stable(NAKACK.java:1354)
>         at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:581)
>         at org.jgroups.protocols.UNICAST.down(UNICAST.java:408)
>         at org.jgroups.protocols.pbcast.STABLE.handleStabilityMessage(STABLE.java:622)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:247)
>         at org.jgroups.protocols.UNICAST.up(UNICAST.java:297)
>         at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:823)
>         at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:686)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:271)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> 2009.07.30 16:28:58 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 38d9e5b6-4d65-20b4-7b41-7c6658e928d6 (172 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 06:12:29 2009
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Fri, 31 Jul 2009 06:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2224) multi-restriction
 pattern throws UnsupportedOpEx
Message-ID: <556477230.1249035149164.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

multi-restriction pattern throws UnsupportedOpEx
------------------------------------------------

                 Key: JBRULES-2224
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2224
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler (expert)
    Affects Versions: 5.0.1.FINAL
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor


rule "same"
when
    $m : ShGraphType( $x25No : x25No, $trans : trans )
      GoType( x25No == $x25No || == ($x25No % 2000), trans != $trans )  #!!!#
    $e : ShType( x25No == $x25No )
    $v : View( elemSet contains $m )
then

Field x25No is an int.

The marked pattern is not flagged in Eclipse, passes the compiler without an error, but crashes at runtime during fact insertion with:

Exception in thread "main" java.lang.UnsupportedOperationException: does not support method call isAllowed(Object object, InternalWorkingMemory workingMemoiry)
	at org.drools.rule.ReturnValueRestriction.isAllowedCachedRight(ReturnValueRestriction.java:252)
	at org.drools.rule.OrCompositeRestriction.isAllowedCachedRight(OrCompositeRestriction.java:51)
	at org.drools.rule.MultiRestrictionFieldConstraint.isAllowedCachedRight(MultiRestrictionFieldConstraint.java:115)
	at org.drools.common.DoubleBetaConstraints.isAllowedCachedRight(DoubleBetaConstraints.java:181)
	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:172)
	at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:360)
	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:344)
	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:184)
	at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:146)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1094)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1045)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:830)
	at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:219)
	at rss.checker.engine.impl.DroolsEngine.insert(DroolsEngine.java:61)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 06:15:29 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Jul 2009 06:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7137) MDBs dont register
 local-jndi-name when provided in jboss.xml
In-Reply-To: <1347556772.1248932189281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <713183371.1249035329266.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved JBAS-7137.
---------------------------------

    Resolution: Rejected


The assertion isn't made on the bases of the existence of an element in the xsd.

I guess you are referring to the 'JMX Notifications' in http://www.jboss.org/community/wiki/JBossMDB of EJB 2 MDBs in AS 4.0.2. In which case we're talking about MBean names, not JNDI names.
Said construct is unsupported in EJB 3 MDBs in AS 5.

Use the forum if you want to discuss new requirements. 

> MDBs dont register local-jndi-name when provided in jboss.xml
> -------------------------------------------------------------
>
>                 Key: JBAS-7137
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7137
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: WIndows, Java 1.6 huge fat fast machine with thousands of terabytes
>            Reporter: Bill Culp
>            Assignee: Carlo de Wolf
>
> MDBs do not register a JNDI name at all even when local-jndi-name is specified in the jboss.xml and can only be looked up using jboss.j2ee:jar=foo, name=fooname, service=EJB3.
> Also start stop destroy create methods as provided for EJB beans in JMX are not provided.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 06:35:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Jul 2009 06:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1016) memory leak in GMS
	protocol
In-Reply-To: <1523793676.1248774569291.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1999913897.1249036529166.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1016:
---------------------------

    Fix Version/s: 2.6.12
                       (was: 2.6.11)


> memory leak in GMS protocol
> ---------------------------
>
>                 Key: JGRP-1016
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1016
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>            Reporter: Miro Selent
>            Assignee: Bela Ban
>             Fix For: 2.6.12, 2.8
>
>
> Found in org.jgroups.protocols.pbcast.GMS in a scenario where members were killed and restarted very frequently and one member is persistently running. The memory consumption icreased very quickly until OutOfMemory.
> Our analysis with JProfiler leads to the following assumption:
> The number of org.jgroups.stack.IpAddress held by merge_ack_collector icreases every time a member was (re)started. 
> These instances were never removed because no MERGE events occured. This is completely clear since there was only one coordinator (the long running member). 
> If GMS receives no MERGE event it never cleans up the stored IpAddress instances in the merge_ack_collector.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 06:37:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Jul 2009 06:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1019) GossipRouter: loops
	at 40% CPU
Message-ID: <436763536.1249036649104.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

GossipRouter: loops at 40% CPU
------------------------------

                 Key: JGRP-1019
                 URL: https://jira.jboss.org/jira/browse/JGRP-1019
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.4.7, 2.6.12, 2.8


main() calls mainLoop() which uses a Scanner to parse the command line. When started without a valid stdin, Scanner loos at 40%. SOLUTION: remove Scanner (tested, it works)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 06:49:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Jul 2009 06:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1020) CLOUD_PING:
 investigate discovery protocol (similar to FILE_PING) on S3 etc
Message-ID: <1656400149.1249037369118.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLOUD_PING: investigate discovery protocol (similar to FILE_PING) on S3 etc
---------------------------------------------------------------------------

                 Key: JGRP-1020
                 URL: https://jira.jboss.org/jira/browse/JGRP-1020
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.x




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 07:53:29 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Fri, 31 Jul 2009 07:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1879) EJB3 Deployment
 Issue on AS trunk
Message-ID: <1058343557.1249041209911.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

EJB3 Deployment Issue on AS trunk
---------------------------------

                 Key: EJBTHREE-1879
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1879
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: 1.1.10
            Reporter: Richard Opalka
             Fix For: 1.1.11
         Attachments: jaxws-jbws1309-client.jar

13:44:55,242 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/opt/svn/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/default/deploy/jaxws-jbws1309.jar/ state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Error deploying jaxws-jbws1309.jar: No container configured with name 'Stateless Bean''
	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:60)
	at org.jboss.deployers.vfs.spi.deployer.AbstractSimpleVFSRealDeployer.deploy(AbstractSimpleVFSRealDeployer.java:56)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
	at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.RuntimeException: No container configured with name 'Stateless Bean''
	at org.jboss.ejb3.Ejb3AnnotationHandler.getStatelessContainer(Ejb3AnnotationHandler.java:310)
	at org.jboss.ejb3.Ejb3DescriptorHandler.getStatelessContainer(Ejb3DescriptorHandler.java:499)
	at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:206)
	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:734)
	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:685)
	at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:667)
	at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:630)
	at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:507)
	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
	... 34 more


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 07:53:30 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Fri, 31 Jul 2009 07:53:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1879) EJB3 Deployment
 Issue on AS trunk
In-Reply-To: <1058343557.1249041209911.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <440849394.1249041210054.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated EJBTHREE-1879:
-------------------------------------

    Attachment: jaxws-jbws1309-client.jar


Client archive

> EJB3 Deployment Issue on AS trunk
> ---------------------------------
>
>                 Key: EJBTHREE-1879
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1879
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.10
>            Reporter: Richard Opalka
>             Fix For: 1.1.11
>
>         Attachments: jaxws-jbws1309-client.jar
>
>
> 13:44:55,242 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/opt/svn/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/default/deploy/jaxws-jbws1309.jar/ state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Error deploying jaxws-jbws1309.jar: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:60)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractSimpleVFSRealDeployer.deploy(AbstractSimpleVFSRealDeployer.java:56)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.RuntimeException: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getStatelessContainer(Ejb3AnnotationHandler.java:310)
> 	at org.jboss.ejb3.Ejb3DescriptorHandler.getStatelessContainer(Ejb3DescriptorHandler.java:499)
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:206)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:734)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:685)
> 	at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:667)
> 	at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:630)
> 	at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:507)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
> 	... 34 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 07:55:29 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Fri, 31 Jul 2009 07:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1879) EJB3 Deployment
 Issue on AS trunk
In-Reply-To: <1058343557.1249041209911.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <495381628.1249041329186.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated EJBTHREE-1879:
-------------------------------------

    Attachment: jaxws-jbws1309.jar


Service jar.

> EJB3 Deployment Issue on AS trunk
> ---------------------------------
>
>                 Key: EJBTHREE-1879
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1879
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.10
>            Reporter: Richard Opalka
>             Fix For: 1.1.11
>
>         Attachments: jaxws-jbws1309-client.jar, jaxws-jbws1309.jar
>
>
> 13:44:55,242 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/opt/svn/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/default/deploy/jaxws-jbws1309.jar/ state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Error deploying jaxws-jbws1309.jar: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:60)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractSimpleVFSRealDeployer.deploy(AbstractSimpleVFSRealDeployer.java:56)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.RuntimeException: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getStatelessContainer(Ejb3AnnotationHandler.java:310)
> 	at org.jboss.ejb3.Ejb3DescriptorHandler.getStatelessContainer(Ejb3DescriptorHandler.java:499)
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:206)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:734)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:685)
> 	at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:667)
> 	at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:630)
> 	at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:507)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
> 	... 34 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 07:55:29 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Fri, 31 Jul 2009 07:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1879) EJB3
 Deployment Issue on AS trunk
In-Reply-To: <1058343557.1249041209911.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <413155676.1249041329260.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478379#action_12478379 ] 

Richard Opalka commented on EJBTHREE-1879:
------------------------------------------

To reproduce the issue just place both jar files to 
JBOSS_TRUNK_HOME/server/default/deploy directory and start AS.

Deployment of these files works fine on AS Branch_5_x

> EJB3 Deployment Issue on AS trunk
> ---------------------------------
>
>                 Key: EJBTHREE-1879
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1879
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.10
>            Reporter: Richard Opalka
>             Fix For: 1.1.11
>
>         Attachments: jaxws-jbws1309-client.jar, jaxws-jbws1309.jar
>
>
> 13:44:55,242 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/opt/svn/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/default/deploy/jaxws-jbws1309.jar/ state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Error deploying jaxws-jbws1309.jar: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:60)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractSimpleVFSRealDeployer.deploy(AbstractSimpleVFSRealDeployer.java:56)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.RuntimeException: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getStatelessContainer(Ejb3AnnotationHandler.java:310)
> 	at org.jboss.ejb3.Ejb3DescriptorHandler.getStatelessContainer(Ejb3DescriptorHandler.java:499)
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:206)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:734)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:685)
> 	at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:667)
> 	at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:630)
> 	at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:507)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
> 	... 34 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 08:01:29 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Fri, 31 Jul 2009 08:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <222264770.1249041689390.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------

    Attachment: QueueExampleLong3.java


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java, QueueExampleLong.java, QueueExampleLong2.java, QueueExampleLong3.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 08:05:29 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Fri, 31 Jul 2009 08:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1822384129.1249041929320.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------

    Attachment: FullSize200_Server.log


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: FullSize200.jpeg, FullSize200_Server.log, QueueExample.java, QueueExampleLong.java, QueueExampleLong2.java, QueueExampleLong3.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 08:05:29 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Fri, 31 Jul 2009 08:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <781785375.1249041929467.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------

    Attachment: FullSize200.jpeg


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: FullSize200.jpeg, FullSize200_Server.log, QueueExample.java, QueueExampleLong.java, QueueExampleLong2.java, QueueExampleLong3.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 08:25:29 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Fri, 31 Jul 2009 08:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1863173241.1249043129384.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------


hi howard, thanks for your feedback. i changed the queue defs as follows:

<mbean code="org.jboss.jms.server.destination.QueueService"
      name="jboss.messaging.destination:service=Queue,name=testQueue"
      xmbean-dd="xmdesc/Queue-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends>jboss.messaging:service=PostOffice</depends>
      <attribute name="MaxDeliveryAttempts">10</attribute>
      <attribute name="FullSize">200</attribute>
      <attribute name="PageSize">100</attribute>
      <attribute name="DownCacheSize">100</attribute>
      <attribute name="SecurityConfig">
         <security>
            <role name="guest" read="true" write="true"/>
            <role name="publisher" read="true" write="true" create="false"/>
            <role name="noacc" read="false" write="false" create="false"/>
         </security>
      </attribute>
   </mbean>

the test case with 100K messages should now occupy a max of about 20MB (200 x 100K). before running the test again i changed the test program to adapt as realistic as possible to our current application logic. so the loop now takes place in the main() method and in the receiving of the messages (MaxDeliveryAttempts set to 10). there is no commit() operation anymore ( see the attached file QueueExampleLong3).
many more 'rounds' can be run with this logic and the above configuration. after about 4060 rounds the OOM in the java heap space occurs again. when running with 500K messages the OOM occurs after 817 rounds (factor 5 matches for sizes and number of rounds). these tests were done with a DLQ specified. i assume that a similar or alike behaviour can be expected with a DLQ as well.
attached you'll also find another screen shot und server log. the screen shot of the jconsole memory view shows the continous growth of memory over time.
thank you very much for your help. kind regards martin



> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: FullSize200.jpeg, FullSize200_Server.log, QueueExample.java, QueueExampleLong.java, QueueExampleLong2.java, QueueExampleLong3.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 08:35:41 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Jul 2009 08:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1021) CLOUD_TCP: more
 scalable impl of TCP
Message-ID: <581113458.1249043741624.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLOUD_TCP: more scalable impl of TCP
------------------------------------

                 Key: JGRP-1021
                 URL: https://jira.jboss.org/jira/browse/JGRP-1021
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.9


See JGroups/doc/design/CLOUD_TCP.txt for details

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 08:56:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Jul 2009 08:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1019) GossipRouter: loops
	at 40% CPU
In-Reply-To: <436763536.1249036649104.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1375154786.1249044989236.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1019:
---------------------------

    Fix Version/s:     (was: 2.8)
                       (was: 2.4.7)


fixed on 2.6.12, not needed on 2.8 as we've already removed the Scanner

> GossipRouter: loops at 40% CPU
> ------------------------------
>
>                 Key: JGRP-1019
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1019
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.6.12
>
>
> main() calls mainLoop() which uses a Scanner to parse the command line. When started without a valid stdin, Scanner loos at 40%. SOLUTION: remove Scanner (tested, it works)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 08:56:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Jul 2009 08:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1019) GossipRouter: loops
	at 40% CPU
In-Reply-To: <436763536.1249036649104.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1313784535.1249044989303.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1019.
----------------------------

    Resolution: Done


> GossipRouter: loops at 40% CPU
> ------------------------------
>
>                 Key: JGRP-1019
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1019
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.6.12
>
>
> main() calls mainLoop() which uses a Scanner to parse the command line. When started without a valid stdin, Scanner loos at 40%. SOLUTION: remove Scanner (tested, it works)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 09:00:30 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Jul 2009 09:00:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1879) EJB3 Deployment
 Issue on AS trunk
In-Reply-To: <1058343557.1249041209911.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1961165696.1249045230717.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf reassigned EJBTHREE-1879:
---------------------------------------

    Assignee: Carlo de Wolf


> EJB3 Deployment Issue on AS trunk
> ---------------------------------
>
>                 Key: EJBTHREE-1879
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1879
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.10
>            Reporter: Richard Opalka
>            Assignee: Carlo de Wolf
>         Attachments: jaxws-jbws1309-client.jar, jaxws-jbws1309.jar
>
>
> 13:44:55,242 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/opt/svn/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/default/deploy/jaxws-jbws1309.jar/ state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Error deploying jaxws-jbws1309.jar: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:60)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractSimpleVFSRealDeployer.deploy(AbstractSimpleVFSRealDeployer.java:56)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.RuntimeException: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getStatelessContainer(Ejb3AnnotationHandler.java:310)
> 	at org.jboss.ejb3.Ejb3DescriptorHandler.getStatelessContainer(Ejb3DescriptorHandler.java:499)
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:206)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:734)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:685)
> 	at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:667)
> 	at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:630)
> 	at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:507)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
> 	... 34 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 09:00:30 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Jul 2009 09:00:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1879) EJB3 Deployment
 Issue on AS trunk
In-Reply-To: <1058343557.1249041209911.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1064802733.1249045230839.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf updated EJBTHREE-1879:
------------------------------------

    Fix Version/s:     (was: 1.1.11)


> EJB3 Deployment Issue on AS trunk
> ---------------------------------
>
>                 Key: EJBTHREE-1879
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1879
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.10
>            Reporter: Richard Opalka
>            Assignee: Carlo de Wolf
>         Attachments: jaxws-jbws1309-client.jar, jaxws-jbws1309.jar
>
>
> 13:44:55,242 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/opt/svn/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/default/deploy/jaxws-jbws1309.jar/ state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Error deploying jaxws-jbws1309.jar: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:60)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractSimpleVFSRealDeployer.deploy(AbstractSimpleVFSRealDeployer.java:56)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.RuntimeException: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getStatelessContainer(Ejb3AnnotationHandler.java:310)
> 	at org.jboss.ejb3.Ejb3DescriptorHandler.getStatelessContainer(Ejb3DescriptorHandler.java:499)
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:206)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:734)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:685)
> 	at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:667)
> 	at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:630)
> 	at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:507)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
> 	... 34 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 09:02:29 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Jul 2009 09:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1879) EJB3 Deployment
 Issue on AS trunk
In-Reply-To: <1058343557.1249041209911.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2016482001.1249045349346.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved EJBTHREE-1879.
-------------------------------------

    Resolution: Done


Build issue in trunk, introduced in JBBUILD-539 rev 91803.

http://fisheye.jboss.org/browse/JBossAS/trunk/ejb3/pom.xml?r1=87828&r2=91803

> EJB3 Deployment Issue on AS trunk
> ---------------------------------
>
>                 Key: EJBTHREE-1879
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1879
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.10
>            Reporter: Richard Opalka
>            Assignee: Carlo de Wolf
>         Attachments: jaxws-jbws1309-client.jar, jaxws-jbws1309.jar
>
>
> 13:44:55,242 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/opt/svn/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/default/deploy/jaxws-jbws1309.jar/ state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Error deploying jaxws-jbws1309.jar: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:60)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractSimpleVFSRealDeployer.deploy(AbstractSimpleVFSRealDeployer.java:56)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.RuntimeException: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getStatelessContainer(Ejb3AnnotationHandler.java:310)
> 	at org.jboss.ejb3.Ejb3DescriptorHandler.getStatelessContainer(Ejb3DescriptorHandler.java:499)
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:206)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:734)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:685)
> 	at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:667)
> 	at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:630)
> 	at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:507)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
> 	... 34 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 09:32:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 31 Jul 2009 09:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1696) Server logs
 should include client's IP in case of client crash
Message-ID: <1032475927.1249047149502.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Server logs should include client's IP in case of client crash
--------------------------------------------------------------

                 Key: JBMESSAGING-1696
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1696
             Project: JBoss Messaging
          Issue Type: Feature Request
            Reporter: Clebert Suconic
            Assignee: Tim Fox
             Fix For: 2.0.0




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 10:04:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Fri, 31 Jul 2009 10:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7130) Stack trace when
 starting up "all" configuration
In-Reply-To: <1446554410.1248826962724.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1719318638.1249049069474.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478408#action_12478408 ] 

Stan Silvert commented on JBAS-7130:
------------------------------------

Same way.  If there is a WAR without a web.xml then add one.

> Stack trace when starting up "all" configuration
> ------------------------------------------------
>
>                 Key: JBAS-7130
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7130
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF, Web (Tomcat) service
>            Reporter: David Lloyd
>            Assignee: Stan Silvert
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> I get the following stack trace when starting up in the "all" configuration:
> 19:19:07,154 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
> 19:19:07,187 WARNING [config] Unable to process deployment descriptor for context '/invoker': java.lang.IllegalArgumentException: InputStream cannot be null
> 	at javax.xml.parsers.SAXParser.parse(SAXParser.java:194)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.scanForFacesServlet(ConfigureListener.java:752)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.<init>(ConfigureListener.java:712)
> 	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:165)
> 	at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:60)
> 	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
> 	at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:462)
> 	at org.jboss.web.deployers.WebModule.startModule(WebModule.java:116)
> 	at org.jboss.web.deployers.WebModule.start(WebModule.java:95)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:207)
> 	at $Proxy38.start(Unknown Source)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:653)
> 	at org.jboss.system.ServiceController.register(ServiceController.java:356)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerRegistrationLifecycleCallback.install(ServiceControllerRegistrationLifecycleCallback.java:104)
> 	at sun.reflect.GeneratedMethodAccessor239.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 10:11:30 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 31 Jul 2009 10:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMAN-91) SerialVersionUID
 test detecting mismatch with org.jboss.managed.plugins.ManagedObjectImpl
In-Reply-To: <2047708221.1246383151330.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1400844825.1249049490038.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMAN-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBMAN-91.
--------------------------------

    Resolution: Won't Fix


Due to the following issues, there was an incompatible change in the serialized format of the MangedObjectImp, so the version was changed to 3, so that is the correct version for 2.1.1.GA on.

JBMAN-86, mark the attachments as transient
JBMAN-87, skip the serialization of the fields ANNOTATIONS


> SerialVersionUID test detecting mismatch with org.jboss.managed.plugins.ManagedObjectImpl
> -----------------------------------------------------------------------------------------
>
>                 Key: JBMAN-91
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-91
>             Project: JBoss Managed
>          Issue Type: Bug
>          Components: general
>            Reporter: Shelly McGowan
>            Assignee: Scott M Stark
>             Fix For: JBossMan.2.1.1.GA 
>
>
> Since 2.1.1.CR1 release, JBoss AS integration testsuite showing this failure when compariing serialVer UIDs to 500 and 501:
> FAIL: serialVersionUID error for org.jboss.managed.plugins.ManagedObjectImpl, 500 2, current: 3
> FAIL: serialVersionUID error for org.jboss.managed.plugins.ManagedObjectImpl, 501 2, current: 3

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 10:35:30 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Fri, 31 Jul 2009 10:35:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
Message-ID: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

EJB2 MDB managed component doesn't report correct CreateCount
-------------------------------------------------------------

                 Key: JBAS-7141
                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.2.0.Beta1
            Reporter: Lukas Krejci
            Assignee: Scott M Stark


The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 10:39:29 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 31 Jul 2009 10:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMAN-65) Support for JMX
	annotations
In-Reply-To: <18968897.1237194022581.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1419037737.1249051169416.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMAN-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark updated JBMAN-65:
-------------------------------

    Fix Version/s: JBoss Managed 2.2.0.GA
                       (was: JBossMan.2.0.1.CR1)


> Support for JMX annotations
> ---------------------------
>
>                 Key: JBMAN-65
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-65
>             Project: JBoss Managed
>          Issue Type: Feature Request
>          Components: managedobject
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBoss Managed 2.2.0.GA
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Feature request from JBAS-5339, Provide support for JSR-255 JMX annotations (@ManagedResource,
> @ManagedAttribute, @ManagedOperation...etc) until Java 7 is supported.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 10:39:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Fri, 31 Jul 2009 10:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
In-Reply-To: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2015704420.1249051169541.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7141:
---------------------------------

    Assignee: Jason T. Greene  (was: Scott M Stark)


Jason, is this a problem with the profile service mapping or the underlying mbean value?

> EJB2 MDB managed component doesn't report correct CreateCount
> -------------------------------------------------------------
>
>                 Key: JBAS-7141
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>
> The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 10:39:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Fri, 31 Jul 2009 10:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
In-Reply-To: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <782727393.1249051169768.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7141:
---------------------------------

    Labels: embjopr1_3  (was: )


> EJB2 MDB managed component doesn't report correct CreateCount
> -------------------------------------------------------------
>
>                 Key: JBAS-7141
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>
> The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 10:45:29 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 31 Jul 2009 10:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAN-92) Reduce log level of
 the "Cannot create String name from non-Simple property" msg
Message-ID: <908984637.1249051529188.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Reduce log level of the "Cannot create String name from non-Simple property" msg
--------------------------------------------------------------------------------

                 Key: JBMAN-92
                 URL: https://jira.jboss.org/jira/browse/JBMAN-92
             Project: JBoss Managed
          Issue Type: Feature Request
    Affects Versions: JBossMan.2.1.1.CR1
            Reporter: Scott M Stark
            Assignee: Scott M Stark
             Fix For: JBossMan.2.1.1.GA , JBoss Managed 2.2.0 Beta1


Related to JBAS-6833, the log level of the msg the default ManagedObjectPopular emits when a value for a property tagged as a ManagementObjectID if the value cannot be obtained should only be a debug level msg as there is no guarantee that a value exists.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 11:23:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 31 Jul 2009 11:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-539) Switch dependency
 resolution to use poms in dist and testsuite instead of in thirdparty.
In-Reply-To: <198920888.1248465209185.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <798537430.1249053809227.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier closed JBBUILD-539.
-----------------------------

    Resolution: Done


POMs in build and testsuite directories are now used for dependency resolution.

> Switch dependency resolution to use poms in dist and testsuite instead of in thirdparty.
> ----------------------------------------------------------------------------------------
>
>                 Key: JBBUILD-539
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-539
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 11:23:29 2009
From: jira-events at lists.jboss.org (steve bucknam (JIRA))
Date: Fri, 31 Jul 2009 11:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-87)
 JBossEntityResolver.loadClasspathResource causes NPE when running via JNI
Message-ID: <358401369.1249053809480.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBossEntityResolver.loadClasspathResource causes NPE when running via JNI
-------------------------------------------------------------------------

                 Key: JBCOMMON-87
                 URL: https://jira.jboss.org/jira/browse/JBCOMMON-87
             Project: JBoss Common
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: common-core (2.x)
    Affects Versions: 2.2.13.GA
         Environment: windows xp 32-bit, MS Visual C++ 2008,  eclipse 3.4.2 with Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
            Reporter: steve bucknam


I created a C++ program the invokes a Java method via JNI.  The classpath is setup to include all required JBoss Cache 3.1.0 jars including JBoss Common.  This method instantiates JBoss Cache as follows:

	    	CacheFactory<String, String> aFactory = new DefaultCacheFactory<String, String>();
	    	Cache cache = aFactory.createCache(configFile);

This causes a NullPointerException in JBossEntityResolver.loadClasspathResource().  The code is as follows:

    ClassLoader loader = Thread.currentThread().getContextClassLoader();
    URL url = loader.getResource(resource);

The ContextClassLoader will always be null when run within JNI.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 11:29:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Fri, 31 Jul 2009 11:29:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
In-Reply-To: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <756233173.1249054169196.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478435#action_12478435 ] 

Lukas Krejci commented on JBAS-7141:
------------------------------------

I added a test app to easily reproduce this: http://anonsvn.jboss.org/repos/jopr/trunk/etc/jbas5-ejb2-mdb-test

Steps:

1) Checkout the above
2) Start an *unsecured* eap5 instance with default conf
3) mvn package
4) sh ./run.sh

> EJB2 MDB managed component doesn't report correct CreateCount
> -------------------------------------------------------------
>
>                 Key: JBAS-7141
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>
> The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:04:30 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 31 Jul 2009 12:04:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1697) Truncated
 files during compacting
Message-ID: <485854682.1249056270177.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Truncated files during compacting
---------------------------------

                 Key: JBMESSAGING-1697
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1697
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0.beta4
            Reporter: Clebert Suconic
            Assignee: Clebert Suconic
             Fix For: 2.0.0


Journal compacting could eventually keep truncated files, what would cause issues during loading or compacting.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:12:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 31 Jul 2009 12:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1697) Truncated
 files during compacting
In-Reply-To: <485854682.1249056270177.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <279713735.1249056749966.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478448#action_12478448 ] 

Clebert Suconic commented on JBMESSAGING-1697:
----------------------------------------------

This bug will cause these exceptions during compacting:

java.lang.IllegalArgumentException
	at java.nio.Buffer.position(Buffer.java:218)
	at org.jboss.messaging.core.journal.impl.JournalImpl.readJournalFile(JournalImpl.java:514)
	at org.jboss.messaging.core.journal.impl.JournalImpl.compact(JournalImpl.java:1480)
	at org.jboss.messaging.core.journal.impl.JournalImpl$3.run(JournalImpl.java:2098)


> Truncated files during compacting
> ---------------------------------
>
>                 Key: JBMESSAGING-1697
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1697
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Journal compacting could eventually keep truncated files, what would cause issues during loading or compacting.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:14:30 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 31 Jul 2009 12:14:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1697) Truncated
 files during compacting
In-Reply-To: <485854682.1249056270177.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <225832351.1249056870073.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1697.
----------------------------------------

    Resolution: Done


> Truncated files during compacting
> ---------------------------------
>
>                 Key: JBMESSAGING-1697
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1697
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Journal compacting could eventually keep truncated files, what would cause issues during loading or compacting.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:23:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-150) API to invoke a XACML
 PDP using SAML2 payload in SOAP messages
Message-ID: <1971872941.1249057409294.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

API to invoke a XACML PDP using SAML2 payload in SOAP messages
--------------------------------------------------------------

                 Key: JBID-150
                 URL: https://jira.jboss.org/jira/browse/JBID-150
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.alpha5


The feature described in http://www.jboss.org/community/wiki/SAMLv2andXACMLv2Integration is a heavily sought after feature in highly secure environments. We need an api to make this XACML authorization request call across to a PDP trying to shield out the complex saml/soap message construction from the user.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:41:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-150) API to invoke a XACML
 PDP using SAML2 payload in SOAP messages
In-Reply-To: <1971872941.1249057409294.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <45931950.1249058489141.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-150.
------------------------------

    Resolution: Done


The wiki has been updated with the API details.

> API to invoke a XACML PDP using SAML2 payload in SOAP messages
> --------------------------------------------------------------
>
>                 Key: JBID-150
>                 URL: https://jira.jboss.org/jira/browse/JBID-150
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> The feature described in http://www.jboss.org/community/wiki/SAMLv2andXACMLv2Integration is a heavily sought after feature in highly secure environments. We need an api to make this XACML authorization request call across to a PDP trying to shield out the complex saml/soap message construction from the user.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:43:41 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:43:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBID-149)
 SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
In-Reply-To: <570484675.1248907889150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1363639827.1249058621142.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana reopened JBID-149:
--------------------------------



> SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
> -----------------------------------------------------------------------
>
>                 Key: JBID-149
>                 URL: https://jira.jboss.org/jira/browse/JBID-149
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:43:41 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:43:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-149)
 SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
In-Reply-To: <570484675.1248907889150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <672555092.1249058621205.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-149:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha5
                       (was: IDFED-1.0.0.beta1)


> SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
> -----------------------------------------------------------------------
>
>                 Key: JBID-149
>                 URL: https://jira.jboss.org/jira/browse/JBID-149
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:43:41 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:43:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-149)
 SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
In-Reply-To: <570484675.1248907889150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1303178027.1249058621356.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-149.
------------------------------

    Resolution: Done


> SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
> -----------------------------------------------------------------------
>
>                 Key: JBID-149
>                 URL: https://jira.jboss.org/jira/browse/JBID-149
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:43:41 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:43:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-132) redirect binding
 computes incorrect signatures for SAML responses
In-Reply-To: <1330676091.1247682749094.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <622182627.1249058621521.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-132:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha5
                       (was: IDFED-1.0.0.beta1)


> redirect binding computes incorrect signatures for SAML responses
> -----------------------------------------------------------------
>
>                 Key: JBID-132
>                 URL: https://jira.jboss.org/jira/browse/JBID-132
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Marcel Kolsteren
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>         Attachments: JBID-132.txt
>
>
> When using the HTTP/Redirect binding with signature support, the signatures for SAMLResponse messages are incorrect. This is caused by the computeSignature method in the RedirectBindingSignatureUtil. This method is called for requests as well as for responses, but when it constructs the string that needs to be signed, it always uses "SAMLRequest":
>       sb.append("SAMLRequest=").append(urlEncodedRequest);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:47:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBID-148) DocumentUtil
 transformer output properties
In-Reply-To: <2080437295.1248907589597.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1508761422.1249058849567.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana reopened JBID-148:
--------------------------------



> DocumentUtil transformer output properties
> ------------------------------------------
>
>                 Key: JBID-148
>                 URL: https://jira.jboss.org/jira/browse/JBID-148
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> transformer.setOutputProperty(OutputKeys.INDENT, "no");

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:47:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-148) DocumentUtil
 transformer output properties
In-Reply-To: <2080437295.1248907589597.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <703904294.1249058849695.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-148.
------------------------------

    Resolution: Done


> DocumentUtil transformer output properties
> ------------------------------------------
>
>                 Key: JBID-148
>                 URL: https://jira.jboss.org/jira/browse/JBID-148
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> transformer.setOutputProperty(OutputKeys.INDENT, "no");

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:47:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-148) DocumentUtil
 transformer output properties
In-Reply-To: <2080437295.1248907589597.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <804772916.1249058849627.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-148:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha5
                       (was: IDFED-1.0.0.beta1)


> DocumentUtil transformer output properties
> ------------------------------------------
>
>                 Key: JBID-148
>                 URL: https://jira.jboss.org/jira/browse/JBID-148
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> transformer.setOutputProperty(OutputKeys.INDENT, "no");

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:47:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBID-146) JAXBUtil: Marshaller
 setProperty formatted output should be false
In-Reply-To: <697355791.1248895829220.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <708751784.1249058849764.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana reopened JBID-146:
--------------------------------



> JAXBUtil: Marshaller setProperty formatted output should be false
> -----------------------------------------------------------------
>
>                 Key: JBID-146
>                 URL: https://jira.jboss.org/jira/browse/JBID-146
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> It will add newlines etc that can invalidate signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:47:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-146) JAXBUtil: Marshaller
 setProperty formatted output should be false
In-Reply-To: <697355791.1248895829220.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <452506895.1249058849833.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-146:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha5
                       (was: IDFED-1.0.0.beta1)


> JAXBUtil: Marshaller setProperty formatted output should be false
> -----------------------------------------------------------------
>
>                 Key: JBID-146
>                 URL: https://jira.jboss.org/jira/browse/JBID-146
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> It will add newlines etc that can invalidate signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:47:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-146) JAXBUtil: Marshaller
 setProperty formatted output should be false
In-Reply-To: <697355791.1248895829220.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <672501674.1249058849926.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-146.
------------------------------

    Resolution: Done


> JAXBUtil: Marshaller setProperty formatted output should be false
> -----------------------------------------------------------------
>
>                 Key: JBID-146
>                 URL: https://jira.jboss.org/jira/browse/JBID-146
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> It will add newlines etc that can invalidate signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:47:30 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:47:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBID-145) IDFedLSInputResolver
 should be made default for schema resolution
In-Reply-To: <1323610313.1248894281013.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1649761146.1249058850141.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana reopened JBID-145:
--------------------------------



> IDFedLSInputResolver should be made default for schema resolution
> -----------------------------------------------------------------
>
>                 Key: JBID-145
>                 URL: https://jira.jboss.org/jira/browse/JBID-145
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:47:30 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:47:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-145) IDFedLSInputResolver
 should be made default for schema resolution
In-Reply-To: <1323610313.1248894281013.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <615716207.1249058850236.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-145:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha5
                       (was: IDFED-1.0.0.beta1)


> IDFedLSInputResolver should be made default for schema resolution
> -----------------------------------------------------------------
>
>                 Key: JBID-145
>                 URL: https://jira.jboss.org/jira/browse/JBID-145
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:47:30 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:47:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-145) IDFedLSInputResolver
 should be made default for schema resolution
In-Reply-To: <1323610313.1248894281013.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <31583897.1249058850366.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-145.
------------------------------

    Resolution: Done


> IDFedLSInputResolver should be made default for schema resolution
> -----------------------------------------------------------------
>
>                 Key: JBID-145
>                 URL: https://jira.jboss.org/jira/browse/JBID-145
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:49:30 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:49:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-130)
 SOAPSAMLXACMLServlet:: PDP in init method
In-Reply-To: <2446024.1245174536331.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <705708849.1249058970001.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-130:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha4
                       (was: IDFED-1.0.0.beta1)


> SOAPSAMLXACMLServlet:: PDP in init method 
> ------------------------------------------
>
>                 Key: JBID-130
>                 URL: https://jira.jboss.org/jira/browse/JBID-130
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> Currently the PDP is creating for each request.  This can be moved to a shared PDP in the servlet and guarded by a lock to provide thread safety.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:49:30 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:49:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-130) SOAPSAMLXACMLServlet::
 PDP in init method
In-Reply-To: <2446024.1245174536331.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1494678642.1249058970067.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-130.
------------------------------

    Resolution: Done


> SOAPSAMLXACMLServlet:: PDP in init method 
> ------------------------------------------
>
>                 Key: JBID-130
>                 URL: https://jira.jboss.org/jira/browse/JBID-130
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> Currently the PDP is creating for each request.  This can be moved to a shared PDP in the servlet and guarded by a lock to provide thread safety.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:49:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBID-130)
 SOAPSAMLXACMLServlet:: PDP in init method
In-Reply-To: <2446024.1245174536331.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1991268147.1249058969932.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana reopened JBID-130:
--------------------------------



> SOAPSAMLXACMLServlet:: PDP in init method 
> ------------------------------------------
>
>                 Key: JBID-130
>                 URL: https://jira.jboss.org/jira/browse/JBID-130
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> Currently the PDP is creating for each request.  This can be moved to a shared PDP in the servlet and guarded by a lock to provide thread safety.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:49:30 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:49:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBID-128)
 DocumentBuilderFactory.setXIncludeAware set to true
In-Reply-To: <15329806.1244654336758.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1055877702.1249058970151.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana reopened JBID-128:
--------------------------------



> DocumentBuilderFactory.setXIncludeAware set to true
> ---------------------------------------------------
>
>                 Key: JBID-128
>                 URL: https://jira.jboss.org/jira/browse/JBID-128
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> DocumentUtil needs to be updated to setXIncludeAware to true on the DocumentBuilderFactory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:49:30 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:49:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-128)
 DocumentBuilderFactory.setXIncludeAware set to true
In-Reply-To: <15329806.1244654336758.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1656929246.1249058970306.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-128.
------------------------------

    Resolution: Done


> DocumentBuilderFactory.setXIncludeAware set to true
> ---------------------------------------------------
>
>                 Key: JBID-128
>                 URL: https://jira.jboss.org/jira/browse/JBID-128
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> DocumentUtil needs to be updated to setXIncludeAware to true on the DocumentBuilderFactory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:49:30 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:49:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-128)
 DocumentBuilderFactory.setXIncludeAware set to true
In-Reply-To: <15329806.1244654336758.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1176508302.1249058970238.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-128:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha4
                       (was: IDFED-1.0.0.beta1)


> DocumentBuilderFactory.setXIncludeAware set to true
> ---------------------------------------------------
>
>                 Key: JBID-128
>                 URL: https://jira.jboss.org/jira/browse/JBID-128
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> DocumentUtil needs to be updated to setXIncludeAware to true on the DocumentBuilderFactory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:49:30 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:49:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBID-84) WS-Trust: SAML Token
	Profile
In-Reply-To: <22333787.1240932058813.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1306008078.1249058970442.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana reopened JBID-84:
-------------------------------



> WS-Trust: SAML Token Profile
> ----------------------------
>
>                 Key: JBID-84
>                 URL: https://jira.jboss.org/jira/browse/JBID-84
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: 1.0.0.alpha2
>            Reporter: Anil Saldhana
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.beta1
>
>
> SOA-692 has requirements.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:51:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-84) WS-Trust: SAML Token
	Profile
In-Reply-To: <22333787.1240932058813.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23654740.1249059089241.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-84:
------------------------------

    Fix Version/s: IDFED-1.0.0.alpha5
                       (was: IDFED-1.0.0.beta1)


> WS-Trust: SAML Token Profile
> ----------------------------
>
>                 Key: JBID-84
>                 URL: https://jira.jboss.org/jira/browse/JBID-84
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: 1.0.0.alpha2
>            Reporter: Anil Saldhana
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.alpha5
>
>
> SOA-692 has requirements.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 12:51:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-84) WS-Trust: SAML Token
	Profile
In-Reply-To: <22333787.1240932058813.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <793061429.1249059089363.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-84.
-----------------------------

    Resolution: Done


> WS-Trust: SAML Token Profile
> ----------------------------
>
>                 Key: JBID-84
>                 URL: https://jira.jboss.org/jira/browse/JBID-84
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: 1.0.0.alpha2
>            Reporter: Anil Saldhana
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.alpha5
>
>
> SOA-692 has requirements.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 13:03:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 13:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-151) SOAPSAMLXACML API
 should handle secure PDPs
Message-ID: <555211862.1249059809185.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SOAPSAMLXACML API should handle secure PDPs
-------------------------------------------

                 Key: JBID-151
                 URL: https://jira.jboss.org/jira/browse/JBID-151
             Project: JBoss Identity
          Issue Type: Sub-task
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1


May require use of Apache HTTPClient or JBoss Netty.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 13:05:42 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 13:05:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-152) IDP should return
 attributes of caller such as email address
Message-ID: <1637862702.1249059942119.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

IDP should return attributes of caller such as email address
------------------------------------------------------------

                 Key: JBID-152
                 URL: https://jira.jboss.org/jira/browse/JBID-152
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1


The IDP should be configurable to return attributes of the subject such as email address etc that can be read from DB, LDAP etc.  This feature will require attribute providers to be plugged in.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 13:12:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 13:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-423)
 RequestAttributeFactory should have method for multi valued attributes
Message-ID: <1726825209.1249060349110.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

RequestAttributeFactory should have method for multi valued attributes
----------------------------------------------------------------------

                 Key: SECURITY-423
                 URL: https://jira.jboss.org/jira/browse/SECURITY-423
             Project: JBoss Security and Identity Management
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JBossXACML
    Affects Versions: jbossxacml_2.0.3.SP2
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: jbossxacml_2.0.4


If there are multiple attribute type values to a single attribute of a single type, then the method can take in an array of values and return the attribute.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 13:14:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 13:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-424) Schema Entity
 Resolver to resolve to local XACML schemas
Message-ID: <537850295.1249060469170.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Schema Entity Resolver to resolve to local XACML schemas
--------------------------------------------------------

                 Key: SECURITY-424
                 URL: https://jira.jboss.org/jira/browse/SECURITY-424
             Project: JBoss Security and Identity Management
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JBossXACML
    Affects Versions: JBossSecurity_2.0.3.SP2
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: jbossxacml_2.0.4


An entity resolver can be used for the JAXB layer that can resolve to local schemas.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 13:14:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 13:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-424) Schema Entity
 Resolver to resolve to local XACML schemas
In-Reply-To: <537850295.1249060469170.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1556132318.1249060469310.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated SECURITY-424:
-----------------------------------

    Affects Version/s: jbossxacml_2.0.3.SP2
                           (was: JBossSecurity_2.0.3.SP2)


> Schema Entity Resolver to resolve to local XACML schemas
> --------------------------------------------------------
>
>                 Key: SECURITY-424
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-424
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossXACML
>    Affects Versions: jbossxacml_2.0.3.SP2
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.4
>
>
> An entity resolver can be used for the JAXB layer that can resolve to local schemas.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 13:28:30 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Fri, 31 Jul 2009 13:28:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7142) EJB 2.0 deployments
 don't have unique JMX names
Message-ID: <1281974921.1249061310027.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

EJB 2.0 deployments don't have unique JMX names
-----------------------------------------------

                 Key: JBAS-7142
                 URL: https://jira.jboss.org/jira/browse/JBAS-7142
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: EAP 5 branch r91843
            Reporter: Ondrej ?i?ka
            Assignee: Jason T. Greene


When  two EARs with EJB 2.0 with the same name are (tried to be) deployed, those EJBs are in conflict in JMX namespace.

Partial stack trace bellow, relevant log lines attached.

-----------------

2009-07-31 19:17:56,499 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessiona.jar",service=EjbModule
javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessiona.jar&quot;,service=EjbModule",type=Component already registered.
	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
	at sun.reflect.GeneratedMethodAccessor75.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)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	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)
2009-07-31 19:17:56,503 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessionb.jar",service=EjbModule
javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessionb.jar&quot;,service=EjbModule",type=Component already registered.
	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
	at sun.reflect.GeneratedMethodAccessor75.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)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	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)
2009-07-31 19:17:56,541 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (ResourceContainer.invoker.nonDaemon-1) Error installing to Real: name=vfszip:/home/brq/ozizka/JoprEmbedded/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/eardeployment1.ear/ state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="sessiona.jar"
	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:118)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	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)
Caused by: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
	at org.jboss.system.ServiceController.install(ServiceController.java:273)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)
	... 44 more



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Fri Jul 31 13:30:29 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Fri, 31 Jul 2009 13:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7142) EJB 2.0 deployments
 don't have unique JMX names
In-Reply-To: <1281974921.1249061310027.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1977751685.1249061429325.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej ?i?ka updated JBAS-7142:
-------------------------------

    Attachment: EJB2_JMX_conflict-log.txt


> EJB 2.0 deployments don't have unique JMX names
> -----------------------------------------------
>
>                 Key: JBAS-7142
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7142
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: EAP 5 branch r91843
>            Reporter: Ondrej ?i?ka
>            Assignee: Jason T. Greene
>         Attachments: eardeployment.ear, EJB2_JMX_conflict-log.txt
>
>
> When  two EARs with EJB 2.0 with the same name are (tried to be) deployed, those EJBs are in conflict in JMX namespace.
> Partial stack trace bellow, relevant log lines attached.
> -----------------
> 2009-07-31 19:17:56,499 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessiona.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessiona.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,503 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessionb.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessionb.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,541 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (ResourceContainer.invoker.nonDaemon-1) Error installing to Real: name=vfszip:/home/brq/ozizka/JoprEmbedded/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/eardeployment1.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="sessiona.jar"
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:118)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> Caused by: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
> 	at org.jboss.system.ServiceController.install(ServiceController.java:273)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)
> 	... 44 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Fri Jul 31 13:30:29 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Fri, 31 Jul 2009 13:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7142) EJB 2.0 deployments
 don't have unique JMX names
In-Reply-To: <1281974921.1249061310027.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <63026864.1249061429684.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej ?i?ka updated JBAS-7142:
-------------------------------

    Attachment: eardeployment.ear


> EJB 2.0 deployments don't have unique JMX names
> -----------------------------------------------
>
>                 Key: JBAS-7142
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7142
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: EAP 5 branch r91843
>            Reporter: Ondrej ?i?ka
>            Assignee: Jason T. Greene
>         Attachments: eardeployment.ear, EJB2_JMX_conflict-log.txt
>
>
> When  two EARs with EJB 2.0 with the same name are (tried to be) deployed, those EJBs are in conflict in JMX namespace.
> Partial stack trace bellow, relevant log lines attached.
> -----------------
> 2009-07-31 19:17:56,499 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessiona.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessiona.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,503 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessionb.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessionb.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,541 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (ResourceContainer.invoker.nonDaemon-1) Error installing to Real: name=vfszip:/home/brq/ozizka/JoprEmbedded/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/eardeployment1.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="sessiona.jar"
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:118)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> Caused by: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
> 	at org.jboss.system.ServiceController.install(ServiceController.java:273)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)
> 	... 44 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Fri Jul 31 13:32:29 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Fri, 31 Jul 2009 13:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7142) EJB 2.0 deployments
 don't have unique JMX names
In-Reply-To: <1281974921.1249061310027.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <184723180.1249061549643.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej ?i?ka updated JBAS-7142:
-------------------------------

    Attachment: eardeployment1.ear


> EJB 2.0 deployments don't have unique JMX names
> -----------------------------------------------
>
>                 Key: JBAS-7142
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7142
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: EAP 5 branch r91843
>            Reporter: Ondrej ?i?ka
>            Assignee: Jason T. Greene
>         Attachments: eardeployment.ear, eardeployment1.ear, EJB2_JMX_conflict-log.txt
>
>
> When  two EARs with EJB 2.0 with the same name are (tried to be) deployed, those EJBs are in conflict in JMX namespace.
> Partial stack trace bellow, relevant log lines attached.
> -----------------
> 2009-07-31 19:17:56,499 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessiona.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessiona.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,503 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessionb.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessionb.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,541 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (ResourceContainer.invoker.nonDaemon-1) Error installing to Real: name=vfszip:/home/brq/ozizka/JoprEmbedded/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/eardeployment1.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="sessiona.jar"
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:118)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> Caused by: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
> 	at org.jboss.system.ServiceController.install(ServiceController.java:273)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)
> 	... 44 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Fri Jul 31 13:36:29 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Fri, 31 Jul 2009 13:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7142) EJB 2.0 deployments
 don't have unique JMX names
In-Reply-To: <1281974921.1249061310027.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <693631772.1249061789643.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej ?i?ka updated JBAS-7142:
-------------------------------

    Description: 
When  two EARs with EJB 2.0 with the same name are (tried to be) deployed, those EJBs are in conflict in JMX namespace.

Partial stack trace bellow, relevant log lines attached.

StR:

1) Deploy ejbdeployment.ear
2) Deploy ejbdeployment1.ear  (a copy of ejbdeployment.ear)
3) Now you get: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.


-----------------

2009-07-31 19:17:56,499 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessiona.jar",service=EjbModule
javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessiona.jar&quot;,service=EjbModule",type=Component already registered.
	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
	at sun.reflect.GeneratedMethodAccessor75.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)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	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)
2009-07-31 19:17:56,503 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessionb.jar",service=EjbModule
javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessionb.jar&quot;,service=EjbModule",type=Component already registered.
	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
	at sun.reflect.GeneratedMethodAccessor75.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)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	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)
2009-07-31 19:17:56,541 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (ResourceContainer.invoker.nonDaemon-1) Error installing to Real: name=vfszip:/home/brq/ozizka/JoprEmbedded/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/eardeployment1.ear/ state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="sessiona.jar"
	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:118)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	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)
Caused by: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
	at org.jboss.system.ServiceController.install(ServiceController.java:273)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)
	... 44 more



  was:
When  two EARs with EJB 2.0 with the same name are (tried to be) deployed, those EJBs are in conflict in JMX namespace.

Partial stack trace bellow, relevant log lines attached.

-----------------

2009-07-31 19:17:56,499 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessiona.jar",service=EjbModule
javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessiona.jar&quot;,service=EjbModule",type=Component already registered.
	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
	at sun.reflect.GeneratedMethodAccessor75.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)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	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)
2009-07-31 19:17:56,503 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessionb.jar",service=EjbModule
javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessionb.jar&quot;,service=EjbModule",type=Component already registered.
	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
	at sun.reflect.GeneratedMethodAccessor75.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)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	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)
2009-07-31 19:17:56,541 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (ResourceContainer.invoker.nonDaemon-1) Error installing to Real: name=vfszip:/home/brq/ozizka/JoprEmbedded/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/eardeployment1.ear/ state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="sessiona.jar"
	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:118)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	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)
Caused by: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
	at org.jboss.system.ServiceController.install(ServiceController.java:273)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)
	... 44 more





> EJB 2.0 deployments don't have unique JMX names
> -----------------------------------------------
>
>                 Key: JBAS-7142
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7142
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: EAP 5 branch r91843
>            Reporter: Ondrej ?i?ka
>            Assignee: Jason T. Greene
>         Attachments: eardeployment.ear, eardeployment1.ear, EJB2_JMX_conflict-log.txt
>
>
> When  two EARs with EJB 2.0 with the same name are (tried to be) deployed, those EJBs are in conflict in JMX namespace.
> Partial stack trace bellow, relevant log lines attached.
> StR:
> 1) Deploy ejbdeployment.ear
> 2) Deploy ejbdeployment1.ear  (a copy of ejbdeployment.ear)
> 3) Now you get: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
> -----------------
> 2009-07-31 19:17:56,499 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessiona.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessiona.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,503 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessionb.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessionb.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,541 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (ResourceContainer.invoker.nonDaemon-1) Error installing to Real: name=vfszip:/home/brq/ozizka/JoprEmbedded/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/eardeployment1.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="sessiona.jar"
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:118)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> Caused by: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
> 	at org.jboss.system.ServiceController.install(ServiceController.java:273)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)
> 	... 44 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Fri Jul 31 13:38:40 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 13:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-423)
 RequestAttributeFactory should have method for multi valued attributes
In-Reply-To: <1726825209.1249060349110.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <890045476.1249061920409.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed SECURITY-423.
----------------------------------

    Resolution: Done


> RequestAttributeFactory should have method for multi valued attributes
> ----------------------------------------------------------------------
>
>                 Key: SECURITY-423
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-423
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossXACML
>    Affects Versions: jbossxacml_2.0.3.SP2
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.4
>
>
> If there are multiple attribute type values to a single attribute of a single type, then the method can take in an array of values and return the attribute.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 14:12:29 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 31 Jul 2009 14:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMAN-92) Reduce log level of
 the "Cannot create String name from non-Simple property" msg
In-Reply-To: <908984637.1249051529188.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <660130104.1249063949355.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMAN-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBMAN-92.
--------------------------------

    Resolution: Done


> Reduce log level of the "Cannot create String name from non-Simple property" msg
> --------------------------------------------------------------------------------
>
>                 Key: JBMAN-92
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-92
>             Project: JBoss Managed
>          Issue Type: Feature Request
>    Affects Versions: JBossMan.2.1.1.CR1
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossMan.2.1.1.GA , JBoss Managed 2.2.0 Beta1
>
>
> Related to JBAS-6833, the log level of the msg the default ManagedObjectPopular emits when a value for a property tagged as a ManagementObjectID if the value cannot be obtained should only be a debug level msg as there is no guarantee that a value exists.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 14:29:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Fri, 31 Jul 2009 14:29:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7143) Upgrade AS 5.2 to
	JSF 2.0.0-Beta2
Message-ID: <1062309899.1249064969694.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade AS 5.2 to JSF 2.0.0-Beta2
---------------------------------

                 Key: JBAS-7143
                 URL: https://jira.jboss.org/jira/browse/JBAS-7143
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JSF
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Stan Silvert
            Assignee: Stan Silvert
             Fix For: JBossAS-5.2.0.Beta1


Upgrade AS 5.2 to JSF 2.0.0-Beta2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 14:34:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 14:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7142) EJB 2.0 deployments
 don't have unique JMX names
In-Reply-To: <1281974921.1249061310027.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <381950545.1249065269297.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene closed JBAS-7142.
---------------------------------

    Resolution: Duplicate Issue


> EJB 2.0 deployments don't have unique JMX names
> -----------------------------------------------
>
>                 Key: JBAS-7142
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7142
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: EAP 5 branch r91843
>            Reporter: Ondrej ?i?ka
>            Assignee: Jason T. Greene
>         Attachments: eardeployment.ear, eardeployment1.ear, EJB2_JMX_conflict-log.txt
>
>
> When  two EARs with EJB 2.0 with the same name are (tried to be) deployed, those EJBs are in conflict in JMX namespace.
> Partial stack trace bellow, relevant log lines attached.
> StR:
> 1) Deploy ejbdeployment.ear
> 2) Deploy ejbdeployment1.ear  (a copy of ejbdeployment.ear)
> 3) Now you get: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
> -----------------
> 2009-07-31 19:17:56,499 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessiona.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessiona.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,503 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessionb.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessionb.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,541 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (ResourceContainer.invoker.nonDaemon-1) Error installing to Real: name=vfszip:/home/brq/ozizka/JoprEmbedded/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/eardeployment1.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="sessiona.jar"
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:118)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> Caused by: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
> 	at org.jboss.system.ServiceController.install(ServiceController.java:273)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)
> 	... 44 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Fri Jul 31 14:34:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 14:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-6335) EjbModule is
	already installed
In-Reply-To: <28094118.1229633874615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1496777112.1249065269584.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene reopened JBAS-6335:
-----------------------------------



AFICT this was never actually fixed. The bug is in EJBDeployer, which in 4.x used to generate a random id.

> EjbModule is already installed
> ------------------------------
>
>                 Key: JBAS-6335
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6335
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows XP jdk1.6.0_11
>            Reporter: Henrik Lindell
>            Assignee: Ales Justin
>            Priority: Blocker
>             Fix For: JBossAS-5.0.1.GA, JBossAS-5.1.0.Beta1
>
>
> When deploying 2 EARs containing each an ejb 2.x jar with the same name ("my-ejbs.jar") deployment fails with this stack trace when the second  is handled by the EjbDeployer.
> The BasicMBeanRegistry tries to register them both with the name "jboss.j2ee:module=&quot;my-ejbs.jar&quot;,service=EjbModule"
> 14:33:27,796 WARN  [AbstractDeploymentContext] Unable to register deployment mbean jboss.j2ee:module="my-ejbs.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;my-ejbs.jar&quot;,service=EjbModule",type=Component already registered.
>         at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:767)
>         at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:236)
>         at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
>         at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
>         at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
>         at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:989)
>         at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:719)
>         at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:249)
>         at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
>         at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
>         at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
>         at org.jboss.Main.boot(Main.java:209)
>         at org.jboss.Main$1.run(Main.java:547)
>         at java.lang.Thread.run(Thread.java:619)
> 14:33:27,828 INFO  [TomcatDeployment] deploy, ctxPath=/abc-6-0-4, vfsUrl=my-ear-6-0-4.ear/webApp.war
> 14:33:28,046 WARN  [TomcatDeployment] Failed to setup clustering, clustering disabled. NoClassDefFoundError: org/jboss/cache/pojo/jmx/PojoCacheJmxWrapperMBean
> 14:33:28,125 INFO  [EjbModule] Deploying AbcSLS
> 14:33:28,203 INFO  [ProxyFactory] Bound EJB Home 'AbcSLS' to jndi 'xyz/abc-6-0-4/internal/ejb/session/Abc'
> 14:33:28,218 INFO  [ProxyFactory] Unbind EJB Home 'AbcSLS' from jndi 'xyz/abc-6-0-4/internal/ejb/session/Abc'
> 14:33:28,218 INFO  [EjbModule] Undeployed AbcSLS
> 14:33:28,218 INFO  [TomcatDeployment] undeploy, ctxPath=/abc-6-0-4, vfsUrl=my-ear-6-0-4.ear/webApp.war
> 14:33:31,015 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/C:/develop/server/jboss-5.0.0.GA.JDK6/server/standard/deploy/my-ear-6-0-4.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="my-ejbs.jar"
>         at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
>         at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:123)
>         at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:45)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
>         at org.jboss.Main.boot(Main.java:209)
>         at org.jboss.Main$1.run(Main.java:547)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.IllegalStateException: jboss.j2ee:module="my-ejbs.jar",service=EjbModule is already installed.
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
>         at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
>         at org.jboss.system.ServiceController.install(ServiceController.java:273)
>         at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:95)
>         ... 24 more
> 14:33:31,093 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS IN ERROR: Name -> Error
> vfsfile:/C:/develop/server/jboss-5.0.0.GA.JDK6/server/standard/deploy/my-ear-6-0-4.ear/ -> java.lang.IllegalStateException: jboss.j2ee:module="my-ejbs.jar",service=EjbModule is already installed.
> 14:33:31,109 INFO  [Http11Protocol] Starting Coyote HTTP/1.1 on http-127.0.0.1-8080
> 14:33:31,140 INFO  [AjpProtocol] Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009
> 14:33:31,140 INFO  [ServerImpl] JBoss (Microcontainer) [5.0.0.GA (build: SVNTag=JBoss_5_0_0_GA date=200812042120)] Started in 1m:40s:531ms

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 14:36:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 14:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6335) EjbModule is
	already installed
In-Reply-To: <28094118.1229633874615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <394131110.1249065389362.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478492#action_12478492 ] 

Jason T. Greene commented on JBAS-6335:
---------------------------------------

Another workaround is to explicitly set the jmx name

> EjbModule is already installed
> ------------------------------
>
>                 Key: JBAS-6335
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6335
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows XP jdk1.6.0_11
>            Reporter: Henrik Lindell
>            Assignee: Ales Justin
>            Priority: Blocker
>             Fix For: JBossAS-5.0.1.GA, JBossAS-5.1.0.Beta1
>
>
> When deploying 2 EARs containing each an ejb 2.x jar with the same name ("my-ejbs.jar") deployment fails with this stack trace when the second  is handled by the EjbDeployer.
> The BasicMBeanRegistry tries to register them both with the name "jboss.j2ee:module=&quot;my-ejbs.jar&quot;,service=EjbModule"
> 14:33:27,796 WARN  [AbstractDeploymentContext] Unable to register deployment mbean jboss.j2ee:module="my-ejbs.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;my-ejbs.jar&quot;,service=EjbModule",type=Component already registered.
>         at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:767)
>         at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:236)
>         at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
>         at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
>         at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
>         at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:989)
>         at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:719)
>         at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:249)
>         at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
>         at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
>         at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
>         at org.jboss.Main.boot(Main.java:209)
>         at org.jboss.Main$1.run(Main.java:547)
>         at java.lang.Thread.run(Thread.java:619)
> 14:33:27,828 INFO  [TomcatDeployment] deploy, ctxPath=/abc-6-0-4, vfsUrl=my-ear-6-0-4.ear/webApp.war
> 14:33:28,046 WARN  [TomcatDeployment] Failed to setup clustering, clustering disabled. NoClassDefFoundError: org/jboss/cache/pojo/jmx/PojoCacheJmxWrapperMBean
> 14:33:28,125 INFO  [EjbModule] Deploying AbcSLS
> 14:33:28,203 INFO  [ProxyFactory] Bound EJB Home 'AbcSLS' to jndi 'xyz/abc-6-0-4/internal/ejb/session/Abc'
> 14:33:28,218 INFO  [ProxyFactory] Unbind EJB Home 'AbcSLS' from jndi 'xyz/abc-6-0-4/internal/ejb/session/Abc'
> 14:33:28,218 INFO  [EjbModule] Undeployed AbcSLS
> 14:33:28,218 INFO  [TomcatDeployment] undeploy, ctxPath=/abc-6-0-4, vfsUrl=my-ear-6-0-4.ear/webApp.war
> 14:33:31,015 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/C:/develop/server/jboss-5.0.0.GA.JDK6/server/standard/deploy/my-ear-6-0-4.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="my-ejbs.jar"
>         at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
>         at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:123)
>         at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:45)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
>         at org.jboss.Main.boot(Main.java:209)
>         at org.jboss.Main$1.run(Main.java:547)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.IllegalStateException: jboss.j2ee:module="my-ejbs.jar",service=EjbModule is already installed.
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
>         at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
>         at org.jboss.system.ServiceController.install(ServiceController.java:273)
>         at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:95)
>         ... 24 more
> 14:33:31,093 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS IN ERROR: Name -> Error
> vfsfile:/C:/develop/server/jboss-5.0.0.GA.JDK6/server/standard/deploy/my-ear-6-0-4.ear/ -> java.lang.IllegalStateException: jboss.j2ee:module="my-ejbs.jar",service=EjbModule is already installed.
> 14:33:31,109 INFO  [Http11Protocol] Starting Coyote HTTP/1.1 on http-127.0.0.1-8080
> 14:33:31,140 INFO  [AjpProtocol] Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009
> 14:33:31,140 INFO  [ServerImpl] JBoss (Microcontainer) [5.0.0.GA (build: SVNTag=JBoss_5_0_0_GA date=200812042120)] Started in 1m:40s:531ms

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 14:38:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 14:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6335) EjbModule is
	already installed
In-Reply-To: <28094118.1229633874615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <553662675.1249065509516.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene reassigned JBAS-6335:
-------------------------------------

    Assignee: Jason T. Greene  (was: Ales Justin)


> EjbModule is already installed
> ------------------------------
>
>                 Key: JBAS-6335
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6335
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows XP jdk1.6.0_11
>            Reporter: Henrik Lindell
>            Assignee: Jason T. Greene
>            Priority: Blocker
>             Fix For: JBossAS-5.0.1.GA, JBossAS-5.1.0.Beta1
>
>
> When deploying 2 EARs containing each an ejb 2.x jar with the same name ("my-ejbs.jar") deployment fails with this stack trace when the second  is handled by the EjbDeployer.
> The BasicMBeanRegistry tries to register them both with the name "jboss.j2ee:module=&quot;my-ejbs.jar&quot;,service=EjbModule"
> 14:33:27,796 WARN  [AbstractDeploymentContext] Unable to register deployment mbean jboss.j2ee:module="my-ejbs.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;my-ejbs.jar&quot;,service=EjbModule",type=Component already registered.
>         at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:767)
>         at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:236)
>         at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
>         at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
>         at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
>         at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:989)
>         at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:719)
>         at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:249)
>         at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
>         at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
>         at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
>         at org.jboss.Main.boot(Main.java:209)
>         at org.jboss.Main$1.run(Main.java:547)
>         at java.lang.Thread.run(Thread.java:619)
> 14:33:27,828 INFO  [TomcatDeployment] deploy, ctxPath=/abc-6-0-4, vfsUrl=my-ear-6-0-4.ear/webApp.war
> 14:33:28,046 WARN  [TomcatDeployment] Failed to setup clustering, clustering disabled. NoClassDefFoundError: org/jboss/cache/pojo/jmx/PojoCacheJmxWrapperMBean
> 14:33:28,125 INFO  [EjbModule] Deploying AbcSLS
> 14:33:28,203 INFO  [ProxyFactory] Bound EJB Home 'AbcSLS' to jndi 'xyz/abc-6-0-4/internal/ejb/session/Abc'
> 14:33:28,218 INFO  [ProxyFactory] Unbind EJB Home 'AbcSLS' from jndi 'xyz/abc-6-0-4/internal/ejb/session/Abc'
> 14:33:28,218 INFO  [EjbModule] Undeployed AbcSLS
> 14:33:28,218 INFO  [TomcatDeployment] undeploy, ctxPath=/abc-6-0-4, vfsUrl=my-ear-6-0-4.ear/webApp.war
> 14:33:31,015 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/C:/develop/server/jboss-5.0.0.GA.JDK6/server/standard/deploy/my-ear-6-0-4.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="my-ejbs.jar"
>         at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
>         at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:123)
>         at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:45)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
>         at org.jboss.Main.boot(Main.java:209)
>         at org.jboss.Main$1.run(Main.java:547)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.IllegalStateException: jboss.j2ee:module="my-ejbs.jar",service=EjbModule is already installed.
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
>         at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
>         at org.jboss.system.ServiceController.install(ServiceController.java:273)
>         at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:95)
>         ... 24 more
> 14:33:31,093 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS IN ERROR: Name -> Error
> vfsfile:/C:/develop/server/jboss-5.0.0.GA.JDK6/server/standard/deploy/my-ear-6-0-4.ear/ -> java.lang.IllegalStateException: jboss.j2ee:module="my-ejbs.jar",service=EjbModule is already installed.
> 14:33:31,109 INFO  [Http11Protocol] Starting Coyote HTTP/1.1 on http-127.0.0.1-8080
> 14:33:31,140 INFO  [AjpProtocol] Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009
> 14:33:31,140 INFO  [ServerImpl] JBoss (Microcontainer) [5.0.0.GA (build: SVNTag=JBoss_5_0_0_GA date=200812042120)] Started in 1m:40s:531ms

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 14:48:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 14:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-425) Ability to
 disable JBossXACML Schema Validation
In-Reply-To: <1554546966.1249066109209.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <971236866.1249066109306.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated SECURITY-425:
-----------------------------------

    Component/s: JBossXACML


> Ability to disable JBossXACML Schema Validation
> -----------------------------------------------
>
>                 Key: SECURITY-425
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-425
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossXACML
>    Affects Versions: jbossxacml_2.0.3.SP2
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.4
>
>
> The *absence* of system property "org.jboss.security.xacml.schema.validation" will always create a validating unmarshaller.
> If you do not want schema validation, then "org.jboss.security.xacml.schema.validation=false"  as system prop.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 14:48:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 14:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-425) Ability to
 disable JBossXACML Schema Validation
Message-ID: <1554546966.1249066109209.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Ability to disable JBossXACML Schema Validation
-----------------------------------------------

                 Key: SECURITY-425
                 URL: https://jira.jboss.org/jira/browse/SECURITY-425
             Project: JBoss Security and Identity Management
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: jbossxacml_2.0.3.SP2
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: jbossxacml_2.0.4


The *absence* of system property "org.jboss.security.xacml.schema.validation" will always create a validating unmarshaller.

If you do not want schema validation, then "org.jboss.security.xacml.schema.validation=false"  as system prop.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 14:48:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 14:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-425) Ability to disable
 JBossXACML Schema Validation
In-Reply-To: <1554546966.1249066109209.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <536010300.1249066109370.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed SECURITY-425.
----------------------------------

    Resolution: Done


> Ability to disable JBossXACML Schema Validation
> -----------------------------------------------
>
>                 Key: SECURITY-425
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-425
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossXACML
>    Affects Versions: jbossxacml_2.0.3.SP2
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.4
>
>
> The *absence* of system property "org.jboss.security.xacml.schema.validation" will always create a validating unmarshaller.
> If you do not want schema validation, then "org.jboss.security.xacml.schema.validation=false"  as system prop.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 14:50:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 14:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-424) Schema Entity
 Resolver to resolve to local XACML schemas
In-Reply-To: <537850295.1249060469170.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <94683937.1249066229122.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed SECURITY-424.
----------------------------------

    Resolution: Done


> Schema Entity Resolver to resolve to local XACML schemas
> --------------------------------------------------------
>
>                 Key: SECURITY-424
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-424
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossXACML
>    Affects Versions: jbossxacml_2.0.3.SP2
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.4
>
>
> An entity resolver can be used for the JAXB layer that can resolve to local schemas.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 15:01:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 15:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
In-Reply-To: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1447409076.1249066889433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478495#action_12478495 ] 

Jason T. Greene commented on JBAS-7141:
---------------------------------------

CreateCount represents the number of application calls to obtaining the home instance of the bean. MDBs do not have a home instance, so the value is 0, this is the way it was on 4 as well. This is different than than the pool stats, which tell you how many instances are in use.

> EJB2 MDB managed component doesn't report correct CreateCount
> -------------------------------------------------------------
>
>                 Key: JBAS-7141
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>
> The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 15:01:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 15:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
In-Reply-To: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1671700022.1249066889576.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene resolved JBAS-7141.
-----------------------------------

    Resolution: Rejected


> EJB2 MDB managed component doesn't report correct CreateCount
> -------------------------------------------------------------
>
>                 Key: JBAS-7141
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>
> The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 15:08:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 15:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7144) JAXR Problems with
 deleted associations
Message-ID: <1089846584.1249067309116.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JAXR Problems with deleted associations
---------------------------------------

                 Key: JBAS-7144
                 URL: https://jira.jboss.org/jira/browse/JBAS-7144
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JAXR service, Test Suite
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: JBossAS-5.2.0.Beta1




==============
tests-scout-jaxr:
    [mkdir] Created dir: /home/anil/Branch_5_x/testsuite/output/log
    [junit] Running org.jboss.test.jaxr.scout.JaxrBaseTestCase     
    [junit] Running org.jboss.test.jaxr.scout.JaxrBaseTestCase     
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.685 sec
    [junit] Running org.jboss.test.jaxr.scout.basic.JaxrJNDIConnectionTestCase
    [junit] Running org.jboss.test.jaxr.scout.basic.JaxrJNDIConnectionTestCase
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.354 sec     
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase
    [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 4.051 sec          
    [junit] Test org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase FAILED
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteOrganizationTestCase   
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteOrganizationTestCase   
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.898 sec              
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveOrganizationTestCase     
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveOrganizationTestCase     
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.687 sec              
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveServiceBindingTestCase   
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveServiceBindingTestCase   
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.705 sec              
    [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase
    [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase
    [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 2.193 sec                
    [junit] Test org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase FAILED
    [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrConfimAssociationTestCase
    [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrConfimAssociationTestCase
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.265 sec                    
    [junit] Running org.jboss.test.jaxr.scout.query.JaxrBusinessQueryTestCase                
    [junit] Running org.jboss.test.jaxr.scout.query.JaxrBusinessQueryTestCase                
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.187 sec                    
    [junit] Running org.jboss.test.jaxr.scout.query.infomodel.JaxrFindAssociationsTestCase   
    [junit] Running org.jboss.test.jaxr.scout.query.infomodel.JaxrFindAssociationsTestCase   
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.505 sec    
==================================

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 15:10:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 15:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-153) Release JBossIdentity
 1.0.0.alpha consolidated stack
Message-ID: <1991426233.1249067429212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Release JBossIdentity 1.0.0.alpha consolidated stack
----------------------------------------------------

                 Key: JBID-153
                 URL: https://jira.jboss.org/jira/browse/JBID-153
             Project: JBoss Identity
          Issue Type: Release
          Components: Community-Build
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 15:10:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 15:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-153) Release JBossIdentity
 1.0.0.alpha5 consolidated stack
In-Reply-To: <1991426233.1249067429212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <251886134.1249067429369.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-153:
-------------------------------

          Summary: Release JBossIdentity 1.0.0.alpha5 consolidated stack  (was: Release JBossIdentity 1.0.0.alpha consolidated stack)
    Fix Version/s: IDENTITY-1.0.0.alpha5


> Release JBossIdentity 1.0.0.alpha5 consolidated stack
> -----------------------------------------------------
>
>                 Key: JBID-153
>                 URL: https://jira.jboss.org/jira/browse/JBID-153
>             Project: JBoss Identity
>          Issue Type: Release
>          Components: Community-Build
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDENTITY-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 15:10:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 15:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7144) JAXR Problems with
 deleted associations
In-Reply-To: <1089846584.1249067309116.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <780691984.1249067429430.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene updated JBAS-7144:
----------------------------------

        Parent:     (was: JBAS-7128)
    Issue Type: Bug  (was: Sub-task)


> JAXR Problems with deleted associations
> ---------------------------------------
>
>                 Key: JBAS-7144
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7144
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: EAP 5.0.0.CR3
>
>
> ==============
> tests-scout-jaxr:
>     [mkdir] Created dir: /home/anil/Branch_5_x/testsuite/output/log
>     [junit] Running org.jboss.test.jaxr.scout.JaxrBaseTestCase     
>     [junit] Running org.jboss.test.jaxr.scout.JaxrBaseTestCase     
>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.685 sec
>     [junit] Running org.jboss.test.jaxr.scout.basic.JaxrJNDIConnectionTestCase
>     [junit] Running org.jboss.test.jaxr.scout.basic.JaxrJNDIConnectionTestCase
>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.354 sec     
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase
>     [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 4.051 sec          
>     [junit] Test org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase FAILED
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteOrganizationTestCase   
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteOrganizationTestCase   
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.898 sec              
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveOrganizationTestCase     
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveOrganizationTestCase     
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.687 sec              
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveServiceBindingTestCase   
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveServiceBindingTestCase   
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.705 sec              
>     [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase
>     [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase
>     [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 2.193 sec                
>     [junit] Test org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase FAILED
>     [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrConfimAssociationTestCase
>     [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrConfimAssociationTestCase
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.265 sec                    
>     [junit] Running org.jboss.test.jaxr.scout.query.JaxrBusinessQueryTestCase                
>     [junit] Running org.jboss.test.jaxr.scout.query.JaxrBusinessQueryTestCase                
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.187 sec                    
>     [junit] Running org.jboss.test.jaxr.scout.query.infomodel.JaxrFindAssociationsTestCase   
>     [junit] Running org.jboss.test.jaxr.scout.query.infomodel.JaxrFindAssociationsTestCase   
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.505 sec    
> ==================================

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 15:10:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 15:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-154) Release JBoss
 Identity Federation Stack 1.0.0.alpha5
Message-ID: <226344186.1249067429464.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Release JBoss Identity Federation Stack 1.0.0.alpha5
----------------------------------------------------

                 Key: JBID-154
                 URL: https://jira.jboss.org/jira/browse/JBID-154
             Project: JBoss Identity
          Issue Type: Sub-task
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.alpha5




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 15:12:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 15:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-154) Release JBoss Identity
 Federation Stack 1.0.0.alpha5
In-Reply-To: <226344186.1249067429464.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <915324633.1249067549164.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-154.
------------------------------

    Resolution: Done


> Release JBoss Identity Federation Stack 1.0.0.alpha5
> ----------------------------------------------------
>
>                 Key: JBID-154
>                 URL: https://jira.jboss.org/jira/browse/JBID-154
>             Project: JBoss Identity
>          Issue Type: Sub-task
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 15:32:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 15:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-153) Release JBossIdentity
 1.0.0.alpha5 consolidated stack
In-Reply-To: <1991426233.1249067429212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <249967620.1249068749146.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-153.
------------------------------

    Resolution: Done


> Release JBossIdentity 1.0.0.alpha5 consolidated stack
> -----------------------------------------------------
>
>                 Key: JBID-153
>                 URL: https://jira.jboss.org/jira/browse/JBID-153
>             Project: JBoss Identity
>          Issue Type: Release
>          Components: Community-Build
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDENTITY-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 15:47:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 15:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-155) Consolidated Build:
 Create IDM Dependency pack
Message-ID: <1255484741.1249069649089.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Consolidated Build:  Create IDM Dependency pack
-----------------------------------------------

                 Key: JBID-155
                 URL: https://jira.jboss.org/jira/browse/JBID-155
             Project: JBoss Identity
          Issue Type: Task
          Components: Community-Build
            Reporter: Anil Saldhana
            Assignee: Jeff Yu


Jeff, we need to create a zip of IDM dependency pack just the way we do for OpenID.

Please take a look at how we do it for openid in:
https://svn.jboss.org/repos/jbossidentity/consolidated-build/trunk/

Just create a module such as jboss-identity-idm  and have the assembly plugin build up the zip.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 15:58:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 31 Jul 2009 15:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
In-Reply-To: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <304272728.1249070309275.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478505#action_12478505 ] 

Ian Springer commented on JBAS-7141:
------------------------------------

Then I don't think it makes sense for the PS or JMX to expose the CreateCount metric at all for MDBs. Is RemoveCount also not applicable to MDBs? I notice for EJB3, createCount and removeCount are not exposed for MDBs.


> EJB2 MDB managed component doesn't report correct CreateCount
> -------------------------------------------------------------
>
>                 Key: JBAS-7141
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>
> The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 15:58:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 31 Jul 2009 15:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
In-Reply-To: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <116325659.1249070309382.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer reopened JBAS-7141:
--------------------------------



> EJB2 MDB managed component doesn't report correct CreateCount
> -------------------------------------------------------------
>
>                 Key: JBAS-7141
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>
> The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 16:47:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 16:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
In-Reply-To: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1864343017.1249073249437.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478509#action_12478509 ] 

Jason T. Greene commented on JBAS-7141:
---------------------------------------

Right same thing, remove translates to the remove() call on the home interface. 

> EJB2 MDB managed component doesn't report correct CreateCount
> -------------------------------------------------------------
>
>                 Key: JBAS-7141
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>
> The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 16:49:29 2009
From: jira-events at lists.jboss.org (Kit Chan (JIRA))
Date: Fri, 31 Jul 2009 16:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2201) Rule got
 executed even does not satisfy LHS after firing an external event in Flow
In-Reply-To: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1412119706.1249073369173.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478510#action_12478510 ] 

Kit Chan commented on JBRULES-2201:
-----------------------------------

I don't have a standalone sample right now, but what I figured out is when a RuleFlowGroup node triggers an external event (from a rule in a drl file), and that event will lead to an End node that ends the main process. Then with the next run of the process (by inserting another fact), what happened is the RuleFlowGroup node that triggered the external event in the last run is trying to execute again with the previous object, which the object is removed from the working memory already, so it ends up with a Null Pointer Exception. I called the dispose method at the end of every run, but seems like it doesn't dispose everything the way it supposed to.

> Rule got executed even does not satisfy LHS after firing an external event in Flow
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2201
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert), drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP SP3, Eclipse 3.4.2
>            Reporter: Kit Chan
>            Assignee: Kris Verlaenen
>            Priority: Critical
>
> I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 16:51:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 16:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
In-Reply-To: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2123931538.1249073489305.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene resolved JBAS-7141.
-----------------------------------

    Resolution: Rejected


> EJB2 MDB managed component doesn't report correct CreateCount
> -------------------------------------------------------------
>
>                 Key: JBAS-7141
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>
> The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 17:01:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 31 Jul 2009 17:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1427) Journal
	Cleanup
In-Reply-To: <6551971.1222785211162.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1015445403.1249074089226.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1427:
-----------------------------------------

    Attachment: diff.patch


The attached patch has a written test showing compacting is needed. The first file will have 500 messages. Compacting will happen frequently because of the messages on the first message.

> Journal Cleanup
> ---------------
>
>                 Key: JBMESSAGING-1427
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1427
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0 Alpha
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>         Attachments: diff.patch
>
>
> If a destination is lazy, not consuming messages for a long time, the journal will grow until those messages are consumed.
> This would be a problem with DLQs or messages taking days before they are consumed.
> Since we inform the TransactionSummary on commits, we could change the journal to support multiple current-files based on configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 17:31:29 2009
From: jira-events at lists.jboss.org (Kit Chan (JIRA))
Date: Fri, 31 Jul 2009 17:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2201) Rule got executed
 even does not satisfy LHS after firing an external event in Flow
In-Reply-To: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1199689479.1249075889228.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kit Chan updated JBRULES-2201:
------------------------------

    Attachment: DroolsTest.java


Test file

> Rule got executed even does not satisfy LHS after firing an external event in Flow
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2201
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert), drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP SP3, Eclipse 3.4.2
>            Reporter: Kit Chan
>            Assignee: Kris Verlaenen
>            Priority: Critical
>         Attachments: DroolsTest.java, SampleObject.java
>
>
> I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 17:31:29 2009
From: jira-events at lists.jboss.org (Kit Chan (JIRA))
Date: Fri, 31 Jul 2009 17:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2201) Rule got executed
 even does not satisfy LHS after firing an external event in Flow
In-Reply-To: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1294089372.1249075889321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kit Chan updated JBRULES-2201:
------------------------------

    Attachment: SampleObject.java


sample object

> Rule got executed even does not satisfy LHS after firing an external event in Flow
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2201
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert), drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP SP3, Eclipse 3.4.2
>            Reporter: Kit Chan
>            Assignee: Kris Verlaenen
>            Priority: Critical
>         Attachments: DroolsTest.java, SampleObject.java
>
>
> I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 17:33:29 2009
From: jira-events at lists.jboss.org (Kit Chan (JIRA))
Date: Fri, 31 Jul 2009 17:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2201) Rule got executed
 even does not satisfy LHS after firing an external event in Flow
In-Reply-To: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <922086545.1249076009236.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kit Chan updated JBRULES-2201:
------------------------------

    Attachment: ruleflow.rf


> Rule got executed even does not satisfy LHS after firing an external event in Flow
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2201
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert), drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP SP3, Eclipse 3.4.2
>            Reporter: Kit Chan
>            Assignee: Kris Verlaenen
>            Priority: Critical
>         Attachments: DroolsTest.java, ruleflow.rf, Sample.drl, SampleObject.java
>
>
> I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 17:33:29 2009
From: jira-events at lists.jboss.org (Kit Chan (JIRA))
Date: Fri, 31 Jul 2009 17:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2201) Rule got executed
 even does not satisfy LHS after firing an external event in Flow
In-Reply-To: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1643873681.1249076009320.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kit Chan updated JBRULES-2201:
------------------------------

    Attachment: Sample.drl


> Rule got executed even does not satisfy LHS after firing an external event in Flow
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2201
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert), drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP SP3, Eclipse 3.4.2
>            Reporter: Kit Chan
>            Assignee: Kris Verlaenen
>            Priority: Critical
>         Attachments: DroolsTest.java, ruleflow.rf, Sample.drl, SampleObject.java
>
>
> I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 17:35:29 2009
From: jira-events at lists.jboss.org (Kit Chan (JIRA))
Date: Fri, 31 Jul 2009 17:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2201) Rule got
 executed even does not satisfy LHS after firing an external event in Flow
In-Reply-To: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1530262728.1249076129568.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478518#action_12478518 ] 

Kit Chan commented on JBRULES-2201:
-----------------------------------

I have attached a sample standalone (drl, rf, test, and object files) that need to run this sample, it will reproduce the error I mentioned, the rule basically just check the value of the object, and print out the object, sometimes it will print out Null, which it shouldn't happen, because if it is null, it won't match the condition in the "when" part and never activate the rule.

> Rule got executed even does not satisfy LHS after firing an external event in Flow
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2201
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert), drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP SP3, Eclipse 3.4.2
>            Reporter: Kit Chan
>            Assignee: Kris Verlaenen
>            Priority: Critical
>         Attachments: DroolsTest.java, ruleflow.rf, Sample.drl, SampleObject.java
>
>
> I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 18:53:29 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Fri, 31 Jul 2009 18:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7145) New logging
 framework breakes JBossWS
Message-ID: <1063164047.1249080809178.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

New logging framework breakes JBossWS
-------------------------------------

                 Key: JBAS-7145
                 URL: https://jira.jboss.org/jira/browse/JBAS-7145
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Richard Opalka
            Assignee: David Lloyd
             Fix For: JBossAS-6.0.0.Alpha1


We're using thirdparty components (to be concrete e.g. Apache WS-Policy)  that require commons-logging artifact that have been removed from AS trunk :(

Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
	at org.apache.ws.policy.util.Loader.<clinit>(Loader.java:32)
	at org.apache.ws.policy.util.PolicyFactory.getPolicyReader(PolicyFactory.java:56)
	at org.jboss.ws.extensions.policy.metadata.PolicyMetaDataBuilder.processPolicyExtensions(PolicyMetaDataBuilder.java:155)
	at org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.buildMetaData(JAXWSClientMetaDataBuilder.java:92)
	at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.<init>(ServiceDelegateImpl.java:138)
	at org.jboss.ws.core.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:63)
	at javax.xml.ws.Service.<init>(Service.java:79)
	at javax.xml.ws.Service.create(Service.java:96)
	at org.jboss.test.ws.jaxws.jbws1666.TestClient.testPortAccess(TestClient.java:38)
	at org.jboss.test.ws.jaxws.jbws1666.TestClient.main(TestClient.java:48)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 18:55:29 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Fri, 31 Jul 2009 18:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7145) New logging
 framework breakes JBossWS
In-Reply-To: <1063164047.1249080809178.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2111034953.1249080929195.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated JBAS-7145:
---------------------------------

          Component/s: Logging
    Affects Version/s: JBossAS-6.0.0.Alpha1


> New logging framework breakes JBossWS
> -------------------------------------
>
>                 Key: JBAS-7145
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7145
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-6.0.0.Alpha1
>            Reporter: Richard Opalka
>            Assignee: David Lloyd
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> We're using thirdparty components (to be concrete e.g. Apache WS-Policy)  that require commons-logging artifact that have been removed from AS trunk :(
> Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
> 	at org.apache.ws.policy.util.Loader.<clinit>(Loader.java:32)
> 	at org.apache.ws.policy.util.PolicyFactory.getPolicyReader(PolicyFactory.java:56)
> 	at org.jboss.ws.extensions.policy.metadata.PolicyMetaDataBuilder.processPolicyExtensions(PolicyMetaDataBuilder.java:155)
> 	at org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.buildMetaData(JAXWSClientMetaDataBuilder.java:92)
> 	at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.<init>(ServiceDelegateImpl.java:138)
> 	at org.jboss.ws.core.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:63)
> 	at javax.xml.ws.Service.<init>(Service.java:79)
> 	at javax.xml.ws.Service.create(Service.java:96)
> 	at org.jboss.test.ws.jaxws.jbws1666.TestClient.testPortAccess(TestClient.java:38)
> 	at org.jboss.test.ws.jaxws.jbws1666.TestClient.main(TestClient.java:48)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 19:14:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 31 Jul 2009 19:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7145) New logging
 framework breakes JBossWS
In-Reply-To: <1063164047.1249080809178.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <453589010.1249082069186.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478523#action_12478523 ] 

David Lloyd commented on JBAS-7145:
-----------------------------------

This class should be present in common/lib/jcl-over-slf4j.jar - I don't know why your deployment isn't seeing it unless maybe you've got some isolated classloading thing going on?

> New logging framework breakes JBossWS
> -------------------------------------
>
>                 Key: JBAS-7145
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7145
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-6.0.0.Alpha1
>            Reporter: Richard Opalka
>            Assignee: David Lloyd
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> We're using thirdparty components (to be concrete e.g. Apache WS-Policy)  that require commons-logging artifact that have been removed from AS trunk :(
> Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
> 	at org.apache.ws.policy.util.Loader.<clinit>(Loader.java:32)
> 	at org.apache.ws.policy.util.PolicyFactory.getPolicyReader(PolicyFactory.java:56)
> 	at org.jboss.ws.extensions.policy.metadata.PolicyMetaDataBuilder.processPolicyExtensions(PolicyMetaDataBuilder.java:155)
> 	at org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.buildMetaData(JAXWSClientMetaDataBuilder.java:92)
> 	at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.<init>(ServiceDelegateImpl.java:138)
> 	at org.jboss.ws.core.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:63)
> 	at javax.xml.ws.Service.<init>(Service.java:79)
> 	at javax.xml.ws.Service.create(Service.java:96)
> 	at org.jboss.test.ws.jaxws.jbws1666.TestClient.testPortAccess(TestClient.java:38)
> 	at org.jboss.test.ws.jaxws.jbws1666.TestClient.main(TestClient.java:48)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 31 20:08:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 31 Jul 2009 20:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7145) New logging
 framework breakes JBossWS
In-Reply-To: <1063164047.1249080809178.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1130946369.1249085309321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478524#action_12478524 ] 

David Lloyd commented on JBAS-7145:
-----------------------------------

Where exactly is this exception coming from?  If this is not something that runs inside the AS, I'm inclined to close this as "Not a bug".

> New logging framework breakes JBossWS
> -------------------------------------
>
>                 Key: JBAS-7145
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7145
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-6.0.0.Alpha1
>            Reporter: Richard Opalka
>            Assignee: David Lloyd
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> We're using thirdparty components (to be concrete e.g. Apache WS-Policy)  that require commons-logging artifact that have been removed from AS trunk :(
> Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
> 	at org.apache.ws.policy.util.Loader.<clinit>(Loader.java:32)
> 	at org.apache.ws.policy.util.PolicyFactory.getPolicyReader(PolicyFactory.java:56)
> 	at org.jboss.ws.extensions.policy.metadata.PolicyMetaDataBuilder.processPolicyExtensions(PolicyMetaDataBuilder.java:155)
> 	at org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.buildMetaData(JAXWSClientMetaDataBuilder.java:92)
> 	at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.<init>(ServiceDelegateImpl.java:138)
> 	at org.jboss.ws.core.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:63)
> 	at javax.xml.ws.Service.<init>(Service.java:79)
> 	at javax.xml.ws.Service.create(Service.java:96)
> 	at org.jboss.test.ws.jaxws.jbws1666.TestClient.testPortAccess(TestClient.java:38)
> 	at org.jboss.test.ws.jaxws.jbws1666.TestClient.main(TestClient.java:48)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  1 14:46:51 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 1 Jul 2009 14:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (EJBTHREE-1860) adda check and
 don't process EJB2 metadata in Ejb3AnnotationHandler
In-Reply-To: <1456911370.1246456851425.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1504647072.1246474011716.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reopened EJBTHREE-1860:
------------------------------------



Re-opening to add the "component"

> adda check and don't process EJB2 metadata in Ejb3AnnotationHandler
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1860
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1860
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: core
>    Affects Versions: 1.1.8
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.1.9
>
>
> This is inspired by JBMETA-208. As I explained in JBMETA-208, EJB2 metadata shouldn't even get that far. But I'll add one if-statement anyway to make sure we don't run into an issue like that again.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 14:56:02 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 1 Jul 2009 14:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7013) Seam Booking
 IOException with JSF2 Beta1 on AS5
In-Reply-To: <23174748.1244831337615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1818232289.1246474562589.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert resolved JBAS-7013.
--------------------------------

    Resolution: Done


Verified fixed in nightly of Mojarra 2.0

> Seam Booking IOException with JSF2 Beta1 on AS5
> -----------------------------------------------
>
>                 Key: JBAS-7013
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7013
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>
> I drop-in replaced JSF in AS5.1 with JSF 2 Beta 1.  
> With the Seam Booking demo, I bundle the old facelets and have:
>    <context-param>
>       <param-name>javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER</param-name>
>       <param-value>true</param-value>
>     </context-param>
> I get the stack trace below.  Though it doesn't seem to affect the application, I need to figure out why this is happening.
> 13:38:34,463 ERROR [compiler] Error Loading Library: vfszip:/C:/jboss-5.1.0.GA/s
> erver/default/deploy/jbossweb.sar/jsf-libs/jsf-impl.jar/META-INF/mojarra_ext.tag
> lib.xml
> java.io.IOException: Error parsing [vfszip:/C:/jboss-5.1.0.GA/server/default/dep
> loy/jbossweb.sar/jsf-libs/jsf-impl.jar/META-INF/mojarra_ext.taglib.xml]:
>         at com.sun.facelets.compiler.TagLibraryConfig.create(TagLibraryConfig.ja
> va:410)
>         at com.sun.facelets.compiler.TagLibraryConfig.loadImplicit(TagLibraryCon
> fig.java:431)
>         at com.sun.facelets.compiler.Compiler.initialize(Compiler.java:87)
>         at com.sun.facelets.compiler.Compiler.compile(Compiler.java:104)
>         at com.sun.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFace
> letFactory.java:218)
>         at com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFacelet
> Factory.java:149)
>         at com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFacelet
> Factory.java:100)
>         at com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java
> :517)
>         at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.jav
> a:567)
>         at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWra
> pper.java:108)
>         at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.j
> ava:216)
>         at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePha
> se.java:124)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:103)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:311)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.web.HotDeployFilter.doFilter(HotDeployFilter.java:53)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter
> .java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFi
> lter.java:96)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:206)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
> alve.java:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
> alve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(Securit
> yAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValv
> e.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.proce
> ss(SecurityContextEstablishmentValve.java:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invok
> e(SecurityContextEstablishmentValve.java:70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
> ava:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
> ava:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedC
> onnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
> ve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
> a:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
> :829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
> ss(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:44
> 7)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: org.xml.sax.SAXException: Error Handling [vfszip:/C:/jboss-5.1.0.GA/s
> erver/default/deploy/jbossweb.sar/jsf-libs/jsf-impl.jar/META-INF/mojarra_ext.tag
> lib.xml at 42,29]
>         at com.sun.facelets.compiler.TagLibraryConfig$LibraryHandler.error(TagLi
> braryConfig.java:376)
>         at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)
>         at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
>         at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
>         at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
>         at org.apache.xerces.impl.dtd.XMLDTDValidator.rootElementSpecified(Unkno
> wn Source)
>         at org.apache.xerces.impl.dtd.XMLDTDValidator.handleStartElement(Unknown
>  Source)
>         at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Sourc
> e)
>         at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElemen
> t(Unknown Source)
>         at org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanR
> ootElementHook(Unknown Source)
>         at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent
> Dispatcher.dispatch(Unknown Source)
>         at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un
> known 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 Sour
> ce)
>         at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
>         at javax.xml.parsers.SAXParser.parse(SAXParser.java:198)
>         at com.sun.facelets.compiler.TagLibraryConfig.create(TagLibraryConfig.ja
> va:407)
>         ... 54 more
> Caused by: org.xml.sax.SAXParseException: Document root element "facelet-taglib"
> , must match DOCTYPE root "null".
>         at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Un
> known Source)
>         ... 73 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 14:48:51 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 1 Jul 2009 14:48:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1860) adda check and
 don't process EJB2 metadata in Ejb3AnnotationHandler
In-Reply-To: <1456911370.1246456851425.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <491705736.1246474131425.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1860.
------------------------------------

    Resolution: Done


> adda check and don't process EJB2 metadata in Ejb3AnnotationHandler
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1860
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1860
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: core
>    Affects Versions: 1.1.8
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.1.9
>
>
> This is inspired by JBMETA-208. As I explained in JBMETA-208, EJB2 metadata shouldn't even get that far. But I'll add one if-statement anyway to make sure we don't run into an issue like that again.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 14:19:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 1 Jul 2009 14:19:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6372) Add data source
 configuration files for Ingres RDBMS support
In-Reply-To: <3379588.1231456084356.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1466498599.1246472391896.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBAS-6372:
----------------------------------

            Issue Type: Feature Request  (was: Patch)
     Original Estimate:     (was: 30 minutes)
    Remaining Estimate:     (was: 30 minutes)
           Component/s: JCA service
                            (was: Other)
              Assignee: Jesper Pedersen
              Priority: Minor  (was: Optional)


> Add data source configuration files for Ingres RDBMS support
> ------------------------------------------------------------
>
>                 Key: JBAS-6372
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6372
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.Beta1, JBossAS-6.0.0.Alpha1, JBossAS-Branch_4_2
>         Environment: N/A
>            Reporter: murray armfield
>            Assignee: Jesper Pedersen
>            Priority: Minor
>         Attachments: create_database.sql, create_database.sql, JBAS-ingres.tar.gz, jboss-soa-p.4.3.0.tar.gz
>
>
> I'm working on getting JBoss going against the Ingres RDBMS database server. I've got some initial config files that can be included as part of the data source configurations. I have other patches for different components, but this issue is just to get two data source definitions added to the jbossas/trunk/connector/src/etc/example-config directory, one for a  local-tx-datasource and one for a xa-datasource.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 13:39:04 2009
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Wed, 1 Jul 2009 13:39:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1000) COMPRESS corrupts
	some messages
In-Reply-To: <7560851.1245854756549.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1061627029.1246469944120.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Reed resolved JGRP-1000.
-------------------------------

    Resolution: Done


Committed to Branch_JGroups_2_4, Branch_JGroups_2_6, and HEAD.

COMPRESS no longer replaces the original message if the compressed version is not smaller.

> COMPRESS corrupts some messages
> -------------------------------
>
>                 Key: JGRP-1000
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1000
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.5
>            Reporter: Dennis Reed
>            Assignee: Dennis Reed
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> COMPRESS.down() stores the compressed message in a temporary buffer the same size as the original message.
> If the compressed size of a message is larger than the original, then part of the message is lost, with no errors reported.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 14:46:51 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 1 Jul 2009 14:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1860) adda check and
 don't process EJB2 metadata in Ejb3AnnotationHandler
In-Reply-To: <1456911370.1246456851425.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1908706879.1246474011894.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1860:
-----------------------------------

    Affects Version/s: 1.1.8


> adda check and don't process EJB2 metadata in Ejb3AnnotationHandler
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1860
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1860
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: core
>    Affects Versions: 1.1.8
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.1.9
>
>
> This is inspired by JBMETA-208. As I explained in JBMETA-208, EJB2 metadata shouldn't even get that far. But I'll add one if-statement anyway to make sure we don't run into an issue like that again.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 14:12:03 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 1 Jul 2009 14:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1257105679.1246471923451.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474506#action_12474506 ] 

Carlo de Wolf commented on JBMETA-208:
--------------------------------------

EJB 3.0 page 497:
"All EJB deployment descriptors must indicate the ejb-jar schema by using the Java EE namespace:

http://java.sun.com/xml/ns/javaee

and by indicating the version of the schema by using the version element as shown below:

    <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
          http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
      version="3.0">
      ...
    </ejb-jar>"

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <ejb-jar version="3.0"
>     xmlns="http://java.sun.com/xml/ns/javaee"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 13:50:52 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 1 Jul 2009 13:50:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <353309018.1246470652029.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474503#action_12474503 ] 

Alexey Loubyansky commented on JBMETA-208:
------------------------------------------

This is what Richard is asking for: "If you have a bean annotated @Stateful or @Stateless in your JAR, but your JAR has an EJB2 deployment descriptor, you should get an error."

> The deployment should have been completely skipped from the EJB3 processing. 

It is now. See related issues.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <ejb-jar version="3.0"
>     xmlns="http://java.sun.com/xml/ns/javaee"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 13:19:51 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Wed, 1 Jul 2009 13:19:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (SECURITY-415)
 ClientLoginModule
 multi-threaded=false should make SecurityContext client side association
In-Reply-To: <12517767.1244524256604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <892470226.1246468791459.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/SECURITY-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474498#action_12474498 ] 

Stefan Guilhen commented on SECURITY-415:
-----------------------------------------

Another possibility is to forbid the use of ClientLoginModule on the server side, as one could easily do SecurityClientFactory.getSecurityClient().performSimpleLogin() to change his security context information. The drawback here is that we would have to clearly document this and it would break applications that currently use the ClientLoginModule on the server side.

> ClientLoginModule multi-threaded=false should make SecurityContext client side association
> ------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-415
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-415
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: JBossSecurity_2.0.3.SP1
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.3.SP2
>
>
> The ClientLoginModule multi-threaded=false option when missing, should set SecurityContextAssociation.setClient()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 14:46:51 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 1 Jul 2009 14:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1860) adda check and
 don't process EJB2 metadata in Ejb3AnnotationHandler
In-Reply-To: <1456911370.1246456851425.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <324093341.1246474011804.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1860:
-----------------------------------

    Component/s: core


> adda check and don't process EJB2 metadata in Ejb3AnnotationHandler
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1860
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1860
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: core
>    Affects Versions: 1.1.8
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.1.9
>
>
> This is inspired by JBMETA-208. As I explained in JBMETA-208, EJB2 metadata shouldn't even get that far. But I'll add one if-statement anyway to make sure we don't run into an issue like that again.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 10:21:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 1 Jul 2009 10:21:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-101) SJC/RADeployer:
	Annotations
Message-ID: <387057390.1246458111738.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC/RADeployer: Annotations
---------------------------

                 Key: JBJCA-101
                 URL: https://jira.jboss.org/jira/browse/JBJCA-101
             Project: JBoss JCA
          Issue Type: Task
          Components: Deployer
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Handle annotations in the resource adapter to build a complete metadata model for the adapter.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 10:17:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 1 Jul 2009 10:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-100) SJC/RADeployer:
	Classloading
Message-ID: <855624937.1246457871714.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC/RADeployer: Classloading
----------------------------

                 Key: JBJCA-100
                 URL: https://jira.jboss.org/jira/browse/JBJCA-100
             Project: JBoss JCA
          Issue Type: Task
          Components: Deployer
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Add a classloader to each deployment unit in the SJC resource adapter deployer.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 10:23:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 1 Jul 2009 10:23:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-102) SJC/RADeployer:
	Merge metadata
Message-ID: <2016998490.1246458231392.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC/RADeployer: Merge metadata
------------------------------

                 Key: JBJCA-102
                 URL: https://jira.jboss.org/jira/browse/JBJCA-102
             Project: JBoss JCA
          Issue Type: Task
          Components: Deployer
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Merge the metadata from the XML and the annotations into a single model.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 06:04:31 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Wed, 1 Jul 2009 06:04:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1675) add netty
 servlet firewall support when available.
Message-ID: <636963632.1246442671919.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

add netty servlet firewall support when available.
--------------------------------------------------

                 Key: JBMESSAGING-1675
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1675
             Project: JBoss Messaging
          Issue Type: Task
    Affects Versions: 2.0.0.beta3
            Reporter: Andy Taylor
            Assignee: Andy Taylor
             Fix For: 2.0.0




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 10:00:51 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 1 Jul 2009 10:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1860) adda check and
 don't process EJB2 metadata in Ejb3AnnotationHandler
Message-ID: <1456911370.1246456851425.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

adda check and don't process EJB2 metadata in Ejb3AnnotationHandler
-------------------------------------------------------------------

                 Key: EJBTHREE-1860
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1860
             Project: EJB 3.0
          Issue Type: Task
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: 1.1.9


This is inspired by JBMETA-208. As I explained in JBMETA-208, EJB2 metadata shouldn't even get that far. But I'll add one if-statement anyway to make sure we don't run into an issue like that again.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 10:08:51 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 1 Jul 2009 10:08:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7070) EJB3 version check
 should be based on JBossMetaData.isEJB3x()
Message-ID: <1783378528.1246457331361.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

EJB3 version check should be based on JBossMetaData.isEJB3x()
-------------------------------------------------------------

                 Key: JBAS-7070
                 URL: https://jira.jboss.org/jira/browse/JBAS-7070
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB3
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: JBossAS-5.2.0.Beta1


org.jboss.ejb3.deployers.Ejb3Deployer does it this way: !(metaData.isEJB2x() || metaData.isEJB1x()). Instead, it should use metaData.isEJB3x(). This is inspired by JBMETA-208.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 06:37:31 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Wed, 1 Jul 2009 06:37:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2153) ODE integration
Message-ID: <1874338443.1246444651278.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

ODE integration
---------------

                 Key: JBRULES-2153
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2153
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-compiler (flow), drools-core (flow)
            Reporter: Kris Verlaenen
            Assignee: Kris Verlaenen
             Fix For: 5.1.0.M1


Allow the execution of WS-BPEL processes by embedding the Apache ODE engine.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 06:02:31 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Wed, 1 Jul 2009 06:02:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1674) add netty
	https support
Message-ID: <91041005.1246442551264.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

add netty https support
-----------------------

                 Key: JBMESSAGING-1674
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1674
             Project: JBoss Messaging
          Issue Type: Task
    Affects Versions: 2.0.0.beta3
            Reporter: Andy Taylor
            Assignee: Andy Taylor
             Fix For: 2.0.0


Netty has has support added for https when using the servlet transport. we need to make sure we support this fully and add an example. This will be available in netty 2.0.0.CR2 upwards

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 12:33:07 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Wed, 1 Jul 2009 12:33:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1429795558.1246465987071.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-6185:
---------------------------------

    Labels: EmbJopr1_3  (was: )


> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Shelly McGowan
>            Priority: Blocker
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 11:17:51 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Wed, 1 Jul 2009 11:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (SECURITY-415)
 ClientLoginModule
 multi-threaded=false should make SecurityContext client side association
In-Reply-To: <12517767.1244524256604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <929026014.1246461471460.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/SECURITY-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474471#action_12474471 ] 

Stefan Guilhen commented on SECURITY-415:
-----------------------------------------

Calling SecurityAssociationContext.setClient() causes many problems when the ClientLoginModule is used on the server side. Consider the ClientLoginModuleEJBUnitCase, where the test calls a bean and this bean performs a login() using the ClientLoginModule. As the multi-threaded property was not set, the module calls setClient() on SecurityContextAssociation, causing all server threads to use the *same* static variable to hold the security contexts. Of course this leads to a huge security flaw.

In my opinion we should not use any variables to differentiate between server and client usage. I think we should have different classes, perhaps different login modules - a ServerLoginModule that never changes the way SecurityContextAssociation works. If we are to use the same module, then we would need separate SecurityContextAssociation implementations - a server side one that stores all contexts in ThreadLocal variables, and a client-side one that offers a vm-wide association of security context via a static variable. In this approach, calling setClient() on the server-side implementation would cause no effects.

> ClientLoginModule multi-threaded=false should make SecurityContext client side association
> ------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-415
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-415
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: JBossSecurity_2.0.3.SP1
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.3.SP2
>
>
> The ClientLoginModule multi-threaded=false option when missing, should set SecurityContextAssociation.setClient()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 11:27:52 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 1 Jul 2009 11:27:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1617) JBM does not
 handle
 java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes()
 when copying a foreign message.
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <400946656.1246462072033.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reopened JBMESSAGING-1617:
-------------------------------------



As discussed with Tim, the current fix, which adds a catch of UnsupportedOperationException, will have big perf impact when the foreign message doesn't support the bytesID. The better way to do is making it an optional behavior by introducing a property into the fix.

Re-open it for the new solution.


> JBM does not handle java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes() when copying a foreign message.
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Some providers can throw UnsupportedOperationException from getCorrelationIDBytes(). This is called in the foreign message constructor of a JBM message. Currently JBM will fail to copy the message since the exception is not handled.
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Wed Jul  1 11:31:52 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Wed, 1 Jul 2009 11:31:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMICROCONT-446)
 bean-deployer xsds don't contain web references
In-Reply-To: <12930376.1245605276537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <733550969.1246462312478.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMICROCONT-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474476#action_12474476 ] 

Wolfgang Knauf commented on JBMICROCONT-446:
--------------------------------------------

About the schema locations in included files: at least Eclipse/WebToolsPlatform does not take the location of the including document, it will complain with a "cannot find" error. Same problem occured for jboss_5_1.xsd, which includes jboss_common_5_1.xsd and which is fixed now.
E.g. the Sun JavaEE xsds all have schema locations with full path in the xsd:includes.

> bean-deployer xsds don't contain web references
> -----------------------------------------------
>
>                 Key: JBMICROCONT-446
>                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-446
>             Project: JBoss Microcontainer
>          Issue Type: Bug
>            Reporter: Wolfgang Knauf
>            Assignee: Kabir Khan
>
> bean-deployer_2_0.xsd:
>    <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">
> =>should point. 
>    <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">
> The comment for a sample instance should also contain a schema location attribute:
>          <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xmlns="urn:jboss:bean-deployer:2.0"
>             xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">
> ==================
> bean-deployer_1_0.xsd:
> The comment for a sample instance should point to the web schema location:
>          <deployment
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
>             xmlns="urn:jboss:bean-deployer">
> =================
> policy_1_0.xsd:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
> should be:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>
> =================
> bean-deployer_2_0.xsd raises validation errors in Eclipse:
> -rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
> -src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
> According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426 ), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 11:31:52 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 1 Jul 2009 11:31:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1288177984.1246462312842.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474477#action_12474477 ] 

jaikiran pai commented on JBMETA-208:
-------------------------------------

>> And if it's EJB2 then does it make sense to look into each class in the JAR to make sure there are no EJB3 annotations? Because this is what you are asking for.

>From my understanding, that's *not* what Richard is asking for. I guess, the point he is trying to make is (based on what i see in the forum post) that some of the deployers processed this as a EJB3 deployment where as the others did not process it. Effectively, this resulted in the deployment having insufficient metadata. As shown in the logs, in that post, we did create the EJB3 services for this deployment (we shouldn't have):

2009-06-15 13:03:33,687 INFO  [org.jboss.ejb3.deployers.JBossASKernel] (main) installing bean: jboss
.j2ee:ear=avant-ss-app.ear,jar=avant-ss-ejb.jar,name=AdviserBean,service=EJB3

The deployment should have been completely skipped from the EJB3 processing. 

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <ejb-jar version="3.0"
>     xmlns="http://java.sun.com/xml/ns/javaee"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 11:29:52 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 1 Jul 2009 11:29:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
In-Reply-To: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2081539651.1246462192366.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7051:
-------------------------------

    Assignee: Scott M Stark  (was: Jason T. Greene)


> ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7051
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ejb3-tutorial-mdb.jar
>
>
> This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:
> 1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.
> 2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:
> container=JBossMQ|JBossMessaging
> which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.
> Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:
> 15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
> ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
> rvice=Queue, parent=JBoss EAP 5 (default)]
> org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
>         at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
>         at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
> rceManager.java:235)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
> figurationUIBean.java:144)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.seam.util.Reflections.invoke(Reflections.java:22)
>         at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
>         at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
> tion(ResourceConfigurationUIBean_$$_javassist_12.java)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
>         at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
>         at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
>         at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
>         at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
>         at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
>         at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
>         at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
>         at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
>         at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
>         at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>         at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>         at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
>         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:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
> a:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
> :70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
> operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
> a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
> ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
> ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
>         ... 84 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 11:31:52 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 1 Jul 2009 11:31:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7050)
 "ClassNotFoundException:
 org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote
 calls to ManagementView.getTemplate()
Message-ID: <2009724766.1246462312306.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7050:
-------------------------------

        Summary: "ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote calls to ManagementView.getTemplate()  (was: Unable to create any kind of datasource or connection factory)
    Component/s: ProfileService


> "ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote calls to ManagementView.getTemplate()
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7050
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7050
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to create a datasource in AS5 using JON, the following exception occurs:
> java.lang.ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo                                                                                               
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)                                                                                            
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)                                                                                                 
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)                                                                                                                         
>         at java.lang.Class.forName0(Native Method)                                                                                                                                               
>         at java.lang.Class.forName(Class.java:247)                                                                                                                                               
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)                                                                   
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)                                                                                                               
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)                                                                                                                  
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)                                                                                                  
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)                                                                                                               
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)                                                                                                              
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)                                                                                                                 
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)                                                        
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)                                                                  
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)                                                                              
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)                                                                                     
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)                                                                        
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)                                                                             
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)                                                                                                 
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                                    
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                                     
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                            
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                          
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                        
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)                                                                                                                
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)                                                             
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> I was only able to find this class in jboss-embedded-all maven module.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 03:37:43 2009
From: jira-events at lists.jboss.org (Christian Daszenies (JIRA))
Date: Wed, 1 Jul 2009 03:37:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7068) Wrong timeout-valiue
 in OracleValidConnectionChecker
Message-ID: <699957358.1246433863204.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Wrong timeout-valiue in OracleValidConnectionChecker
----------------------------------------------------

                 Key: JBAS-7068
                 URL: https://jira.jboss.org/jira/browse/JBAS-7068
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA service
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Christian Daszenies
            Assignee: Jesper Pedersen


OracleValidConnectionChecker calls 
oracle.jdbc.driver.OracleConnection.pingDatabase(5000) - 5000 is used as timeout in seconds! by pingDatabase
furthermore it would be nice if the timeout would be configurable (or at least easy to override)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 04:07:31 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 1 Jul 2009 04:07:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-208) Provide an annotation
 based tutorial for JBossXB
Message-ID: <1932767477.1246435651400.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Provide an annotation based tutorial for JBossXB
------------------------------------------------

                 Key: JBXB-208
                 URL: https://jira.jboss.org/jira/browse/JBXB-208
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
            Reporter: Thomas Diesler


You've specified the namespace using JBossXmlSchema annotation. Which is correct. You should still add namespace element to the XmlRootElement annotation, which is a bit confusing having JBossXmlSchema. You don't have to do that XmlElement annotations.

Unfortunately, we don't have JAXB tutorial for JBossXB. But you can find one for JAXB on Sun's web-site and use javadoc. For examples you can see tests in XB http://anonsvn.jboss.org/repos/common/jbossxb/trunk/src/test/java/org/jboss/test/xb/builder/object/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 05:37:31 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 1 Jul 2009 05:37:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1531) Consider
 multi-thread replication
In-Reply-To: <32708745.1236102742737.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2064547041.1246441051660.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reopened JBMESSAGING-1531:
--------------------------------------



> Consider multi-thread replication
> ---------------------------------
>
>                 Key: JBMESSAGING-1531
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1531
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.1.0.beta
>
>
> Because of the indeterminism of multi-threading, replication is performed over a single thread which has consequences for throughput.
> Multi-thread replication is a very tricky area but we should consider possible approaches here

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 05:39:31 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 1 Jul 2009 05:39:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1531) Consider
 multi-thread replication
In-Reply-To: <32708745.1236102742737.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1419063938.1246441171474.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1531.
------------------------------------

    Resolution: Duplicate Issue


> Consider multi-thread replication
> ---------------------------------
>
>                 Key: JBMESSAGING-1531
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1531
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Because of the indeterminism of multi-threading, replication is performed over a single thread which has consequences for throughput.
> Multi-thread replication is a very tricky area but we should consider possible approaches here

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 05:37:31 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 1 Jul 2009 05:37:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1531) Consider
 multi-thread replication
In-Reply-To: <32708745.1236102742737.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1014301418.1246441051553.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1531.
------------------------------------

    Resolution: Duplicate Issue


> Consider multi-thread replication
> ---------------------------------
>
>                 Key: JBMESSAGING-1531
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1531
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.1.0.beta
>
>
> Because of the indeterminism of multi-threading, replication is performed over a single thread which has consequences for throughput.
> Multi-thread replication is a very tricky area but we should consider possible approaches here

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 05:39:31 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 1 Jul 2009 05:39:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1531) Consider
 multi-thread replication
In-Reply-To: <32708745.1236102742737.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1253972522.1246441171361.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated JBMESSAGING-1531:
-------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.1.0.beta)


> Consider multi-thread replication
> ---------------------------------
>
>                 Key: JBMESSAGING-1531
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1531
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Because of the indeterminism of multi-threading, replication is performed over a single thread which has consequences for throughput.
> Multi-thread replication is a very tricky area but we should consider possible approaches here

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 08:50:06 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 1 Jul 2009 08:50:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-4905) Resolve EJB3 / Web
 Service integration issues
In-Reply-To: <10015790.1193234941460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1227800467.1246452606634.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved JBAS-4905.
---------------------------------

    Fix Version/s:     (was: Backlog)
       Resolution: Out of Date


The WebServiceRef usage should not be an issue anymore. Other potential JBossWS integration issues should be raised individually.

> Resolve EJB3 / Web Service integration issues
> ---------------------------------------------
>
>                 Key: JBAS-4905
>                 URL: https://jira.jboss.org/jira/browse/JBAS-4905
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>            Assignee: Carlo de Wolf
>
> This is a container for relevant ejb3/jbossws integration issues

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 03:41:31 2009
From: jira-events at lists.jboss.org (Christian Daszenies (JIRA))
Date: Wed, 1 Jul 2009 03:41:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7069)
 BaseWrapperManagedConnection
 tries to close a probaby unusable connection without any timeouts
Message-ID: <1307120006.1246434091331.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

BaseWrapperManagedConnection tries to close a probaby unusable connection without any timeouts
----------------------------------------------------------------------------------------------

                 Key: JBAS-7069
                 URL: https://jira.jboss.org/jira/browse/JBAS-7069
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.2.3.GA
            Reporter: Christian Daszenies


org/jboss/resource/adapter/jdbc/BaseWrapperManagedConnection calls con.close() in destroy()  on a probably unusable and not responding connection.

destroy() is called when a (OracleValid)ConnectionChecker marks a connection as unusable, in our case because of a timeout in isValidConnection(Connection)
when BaseWrapperManagedConnection calls close() on the same connection the process hangs infinitely



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 10:02:52 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 1 Jul 2009 10:02:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-1860) adda check and
 don't process EJB2 metadata in Ejb3AnnotationHandler
In-Reply-To: <1456911370.1246456851425.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1741263283.1246456972121.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed EJBTHREE-1860.
---------------------------------------

    Resolution: Done


Done.

> adda check and don't process EJB2 metadata in Ejb3AnnotationHandler
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1860
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1860
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 1.1.9
>
>
> This is inspired by JBMETA-208. As I explained in JBMETA-208, EJB2 metadata shouldn't even get that far. But I'll add one if-statement anyway to make sure we don't run into an issue like that again.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 10:10:51 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 1 Jul 2009 10:10:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7070) EJB3 version check
 should be based on JBossMetaData.isEJB3x()
In-Reply-To: <1783378528.1246457331361.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <723013466.1246457451535.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBAS-7070.
-----------------------------------

    Resolution: Done


Done.

> EJB3 version check should be based on JBossMetaData.isEJB3x()
> -------------------------------------------------------------
>
>                 Key: JBAS-7070
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7070
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> org.jboss.ejb3.deployers.Ejb3Deployer does it this way: !(metaData.isEJB2x() || metaData.isEJB1x()). Instead, it should use metaData.isEJB3x(). This is inspired by JBMETA-208.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 10:27:51 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 1 Jul 2009 10:27:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1732) Pooling
 strategy and configuration information needed at runtime
In-Reply-To: <13056858.1235139524527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <183589543.1246458471360.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474465#action_12474465 ] 

Carlo de Wolf commented on EJBTHREE-1732:
-----------------------------------------

The pooling (and caching) configuration must be visible through JMX / console.

> Pooling strategy and configuration information needed at runtime
> ----------------------------------------------------------------
>
>                 Key: EJBTHREE-1732
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1732
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: ejb3
>    Affects Versions: AS 4.2.3.GA, 1.0.0-Beta10
>            Reporter: Galder Zamarreno
>
> There needs to be a way at runtime to see what pooling strategy (including configuration options) an 
> EJB3 bean is using. Currently, the only way to see this is by enabling TRACE on org.jboss.ejb3 and 
> making an invocation to that EJB3 bean.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 09:50:51 2009
From: jira-events at lists.jboss.org (Jaroslaw Kijanowski (JIRA))
Date: Wed, 1 Jul 2009 09:50:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2154) equality
 assertion behavior not supported in streams
Message-ID: <1255777094.1246456251487.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

equality assertion behavior not supported in streams
----------------------------------------------------

                 Key: JBRULES-2154
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2154
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler (fusion)
    Affects Versions: 5.0.1.FINAL
            Reporter: Jaroslaw Kijanowski
            Assignee: Edson Tirelli


Happens with 5.0.1 and trunk 27324

I've configured my knowledge base to use the EQUALITY assertion behavior.
When I insert two equal facts into the session, only one gets processed (objects and their fact handles are equal).
However when I insert two equal facts via streams, my rule fires twice (objects are equal, but their fact handles are not). Isn't equality assertion behavior supported when using streams?

Attaching rule, model and test class.
If you run it you will see following output:

equal
1

That's expected. If you remove the comment from
WorkingMemoryEntryPoint stream = ...
FactHandle fh1 = stream.insert(message1);
FactHandle fh2 = stream.insert(message2);

and comment out
FactHandle fh1 = ksession.insert(message1);
FactHandle fh2 = ksession.insert(message2);

and modify the rule file to use streams (just remove comments)

you will get this output:

1
1

Means the rule fired twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 03:29:31 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 1 Jul 2009 03:29:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-202) BeansDeployer
 cannot be recycled
In-Reply-To: <1676631077.1246377488627.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <940889806.1246433371297.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBDEPLOY-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474392#action_12474392 ] 

Thomas Diesler commented on JBDEPLOY-202:
-----------------------------------------

JBossXBHelper helper fixed in jbossxb-2.0.2-SNAPSHOT

> BeansDeployer cannot be recycled
> --------------------------------
>
>                 Key: JBDEPLOY-202
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-202
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: classloading
>    Affects Versions: JBDEPLOY-2.0.5.GA
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For:  JBDEPLOY-2.2.x
>
>
> Caused by: java.lang.ClassCastException
> at java.lang.Class.cast(Class.java:2990)
> at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:215)
> at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:170)
> at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:132)
> at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:118)
> at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parseAndInit(AbstractVFSParsingDeployer.java:256)
> at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:239)
> at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:330)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 03:33:31 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 1 Jul 2009 03:33:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-202) BeansDeployer
 cannot be recycled
In-Reply-To: <1676631077.1246377488627.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1711804327.1246433611788.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBDEPLOY-202.
-------------------------------------

    Resolution: Done


Done.

* Allow overwrite of JBossXBHelper. 
* Use jbossxb-2.0.2-SNAPSHOT

in Branch_2_0 and trunk (-r90735)

> BeansDeployer cannot be recycled
> --------------------------------
>
>                 Key: JBDEPLOY-202
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-202
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: classloading
>    Affects Versions: JBDEPLOY-2.0.5.GA
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For:  JBDEPLOY-2.2.x
>
>
> Caused by: java.lang.ClassCastException
> at java.lang.Class.cast(Class.java:2990)
> at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:215)
> at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:170)
> at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:132)
> at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:118)
> at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parseAndInit(AbstractVFSParsingDeployer.java:256)
> at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:239)
> at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:330)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 09:52:51 2009
From: jira-events at lists.jboss.org (Jaroslaw Kijanowski (JIRA))
Date: Wed, 1 Jul 2009 09:52:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2154) equality
 assertion behavior not supported in streams
In-Reply-To: <1255777094.1246456251487.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <601196211.1246456371842.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jaroslaw Kijanowski updated JBRULES-2154:
-----------------------------------------

    Component/s: drools-core (fusion)
                     (was: drools-compiler (fusion))


> equality assertion behavior not supported in streams
> ----------------------------------------------------
>
>                 Key: JBRULES-2154
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2154
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (fusion)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Jaroslaw Kijanowski
>            Assignee: Edson Tirelli
>         Attachments: DroolsTest.java, Message.java, Sample.drl
>
>
> Happens with 5.0.1 and trunk 27324
> I've configured my knowledge base to use the EQUALITY assertion behavior.
> When I insert two equal facts into the session, only one gets processed (objects and their fact handles are equal).
> However when I insert two equal facts via streams, my rule fires twice (objects are equal, but their fact handles are not). Isn't equality assertion behavior supported when using streams?
> Attaching rule, model and test class.
> If you run it you will see following output:
> equal
> 1
> That's expected. If you remove the comment from
> WorkingMemoryEntryPoint stream = ...
> FactHandle fh1 = stream.insert(message1);
> FactHandle fh2 = stream.insert(message2);
> and comment out
> FactHandle fh1 = ksession.insert(message1);
> FactHandle fh2 = ksession.insert(message2);
> and modify the rule file to use streams (just remove comments)
> you will get this output:
> 1
> 1
> Means the rule fired twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 10:32:03 2009
From: jira-events at lists.jboss.org (Prem Stephen (JIRA))
Date: Wed, 1 Jul 2009 10:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2154) equality
 assertion behavior not supported in streams
In-Reply-To: <1255777094.1246456251487.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <956434639.1246458723138.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474466#action_12474466 ] 

Prem Stephen commented on JBRULES-2154:
---------------------------------------

Kindly let me know if this issue is related as well
https://jira.jboss.org/jira/browse/GUVNOR-354

> equality assertion behavior not supported in streams
> ----------------------------------------------------
>
>                 Key: JBRULES-2154
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2154
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (fusion)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Jaroslaw Kijanowski
>            Assignee: Edson Tirelli
>         Attachments: DroolsTest.java, Message.java, Sample.drl
>
>
> Happens with 5.0.1 and trunk 27324
> I've configured my knowledge base to use the EQUALITY assertion behavior.
> When I insert two equal facts into the session, only one gets processed (objects and their fact handles are equal).
> However when I insert two equal facts via streams, my rule fires twice (objects are equal, but their fact handles are not). Isn't equality assertion behavior supported when using streams?
> Attaching rule, model and test class.
> If you run it you will see following output:
> equal
> 1
> That's expected. If you remove the comment from
> WorkingMemoryEntryPoint stream = ...
> FactHandle fh1 = stream.insert(message1);
> FactHandle fh2 = stream.insert(message2);
> and comment out
> FactHandle fh1 = ksession.insert(message1);
> FactHandle fh2 = ksession.insert(message2);
> and modify the rule file to use streams (just remove comments)
> you will get this output:
> 1
> 1
> Means the rule fired twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 09:52:51 2009
From: jira-events at lists.jboss.org (Jaroslaw Kijanowski (JIRA))
Date: Wed, 1 Jul 2009 09:52:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2154) equality
 assertion behavior not supported in streams
In-Reply-To: <1255777094.1246456251487.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <443430062.1246456371954.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jaroslaw Kijanowski updated JBRULES-2154:
-----------------------------------------

    Attachment: DroolsTest.java
                Message.java
                Sample.drl


> equality assertion behavior not supported in streams
> ----------------------------------------------------
>
>                 Key: JBRULES-2154
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2154
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (fusion)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Jaroslaw Kijanowski
>            Assignee: Edson Tirelli
>         Attachments: DroolsTest.java, Message.java, Sample.drl
>
>
> Happens with 5.0.1 and trunk 27324
> I've configured my knowledge base to use the EQUALITY assertion behavior.
> When I insert two equal facts into the session, only one gets processed (objects and their fact handles are equal).
> However when I insert two equal facts via streams, my rule fires twice (objects are equal, but their fact handles are not). Isn't equality assertion behavior supported when using streams?
> Attaching rule, model and test class.
> If you run it you will see following output:
> equal
> 1
> That's expected. If you remove the comment from
> WorkingMemoryEntryPoint stream = ...
> FactHandle fh1 = stream.insert(message1);
> FactHandle fh2 = stream.insert(message2);
> and comment out
> FactHandle fh1 = ksession.insert(message1);
> FactHandle fh2 = ksession.insert(message2);
> and modify the rule file to use streams (just remove comments)
> you will get this output:
> 1
> 1
> Means the rule fired twice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 09:52:52 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 1 Jul 2009 09:52:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1630882893.1246456372318.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474455#action_12474455 ] 

Alexey Loubyansky commented on JBMETA-208:
------------------------------------------

For the record, I am adding a check to Ejb3AnnotationHandler (right before the possible JBMETA-4 warning) whether the metadata is version 3.x and if it's not an exception is thrown:
"Attempt to process non-EJB3.x EJB-JAR metadata as EJB3.x for deployment " + deployment.getName()

But then again I am fixing other parts in the deployers where EJB2 metadata should not pass through. So, EJB2 metadata won't reach Ejb3AnnotationHandler.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <ejb-jar version="3.0"
>     xmlns="http://java.sun.com/xml/ns/javaee"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 09:21:51 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 1 Jul 2009 09:21:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMICROCONT-446)
 bean-deployer xsds don't contain web references
In-Reply-To: <12930376.1245605276537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2032267583.1246454511494.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMICROCONT-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474450#action_12474450 ] 

David Lloyd commented on JBMICROCONT-446:
-----------------------------------------

I recently changed the <xsd:redefine> in bean-deployer_2_0.xsd to <xsd:include>; but I don't see why there must be an absolute URL for the location.  My understanding is that the schema location will be resolved against the including schema's location (which is exactly what we want, no?)

Also these items:

-rcase-RecurseLax.2: There is not a complete functional mapping between the particles.
-src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated: 'rcase-RecurseLax.2'. 

should be fixed by that change.(at least, IDEA doesn't complain about it anymore).

> bean-deployer xsds don't contain web references
> -----------------------------------------------
>
>                 Key: JBMICROCONT-446
>                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-446
>             Project: JBoss Microcontainer
>          Issue Type: Bug
>            Reporter: Wolfgang Knauf
>            Assignee: Kabir Khan
>
> bean-deployer_2_0.xsd:
>    <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">
> =>should point. 
>    <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">
> The comment for a sample instance should also contain a schema location attribute:
>          <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xmlns="urn:jboss:bean-deployer:2.0"
>             xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">
> ==================
> bean-deployer_1_0.xsd:
> The comment for a sample instance should point to the web schema location:
>          <deployment
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
>             xmlns="urn:jboss:bean-deployer">
> =================
> policy_1_0.xsd:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
> should be:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>
> =================
> bean-deployer_2_0.xsd raises validation errors in Eclipse:
> -rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
> -src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
> According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426 ), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 09:37:51 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 1 Jul 2009 09:37:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <659233423.1246455471457.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474452#action_12474452 ] 

Alexey Loubyansky commented on JBMETA-208:
------------------------------------------

I still don't like it... The thing is we don't want to look whether there are classes that (accidentally or not) have EJB3 annotations in an EJB2 deployment.
When a JAR is deployed, we first look whether there is an ejb-jar.xml. And if it's there we can tell by its version which EJB version this deployment is. And if it's EJB2 then does it make sense to look into each class in the JAR to make sure there are no EJB3 annotations? Because this is what you are asking for. It's rather expensive performance-wise.

I understand it's something that used to work. But it shouldn't have worked in the first place. It should actually be considered a bug in JBoss 4.2.3.GA.

PS: regarding the JBMETA-4 warning, I've found a few places where EJB2 deployment could slip through into the EJB3 deployers layer which I am going to fix. But the warning is actually a different issue which accidentally popped up here.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <ejb-jar version="3.0"
>     xmlns="http://java.sun.com/xml/ns/javaee"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 09:39:51 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 1 Jul 2009 09:39:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1617) JBM does not
 handle
 java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes()
 when copying a foreign message.
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1575829431.1246455591802.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1617.
-----------------------------------



done

> JBM does not handle java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes() when copying a foreign message.
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Some providers can throw UnsupportedOperationException from getCorrelationIDBytes(). This is called in the foreign message constructor of a JBM message. Currently JBM will fail to copy the message since the exception is not handled.
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Wed Jul  1 10:17:51 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 1 Jul 2009 10:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1006) Shared transport:
 shunned multiple channels can not reconnect
In-Reply-To: <1360522755.1246439551381.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <544314707.1246457871592.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474460#action_12474460 ] 

Vladimir Blagojevic commented on JGRP-1006:
-------------------------------------------

Commit set on BRANCH 2.6:
Configurator.java 1.28.4.9

> Shared transport: shunned multiple channels can not reconnect 
> --------------------------------------------------------------
>
>                 Key: JGRP-1006
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1006
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6
>            Reporter: Vladimir Blagojevic
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11
>
>
> Brian Stansberry said:
> One of the EJB3/AS integration testsuite runs hit a JGroups problem last 
> night. *Looks like* some issue between the two AS nodes (127.0.0.1 and 
> 127.0.0.2) in the test caused the channels in one node to be 
> suspected/reconnect. Which didn't go well -- which is the subject of 
> this thread.
> I have the server logs from both, which record at INFO or above; if 
> anyone wants them, ping me. Here are the highlights:
> 1) Both nodes connect 4 channels as part of AS startup: 3 using a shared 
> transport UDP stack (for JBC, HAPartition, JBM) and one TCP one for JBM.
> 2) A bunch of test cases then execute, each deploys an EJB3 jar on each 
> node in turn, which in turn causes another JBC channel to be created and 
> connect at test start and disconnect and close at test end. This channel 
> uses the same shared  transport as the other 3, so now there are four 
> channels using that shared transport.
> 3) This create/close cycle continues a while, until on one node there is 
> some issue that results in one of the 4 UDP channels suspecting its peer 
> and all 4 UDP channels getting a new view:
> 13:23:58,150 INFO  [DefaultPartition] Suspected member: 127.0.0.1:40089
> 13:23:58,257 INFO  [GroupMember] 
> org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 4cfcb4de 
> got new view [127.0.0.2:42088|2] [127.0.0.2:42088], old view is 
> [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088]
> 13:23:58,257 INFO  [GroupMember] I am (127.0.0.2:42088)
> 13:23:58,265 INFO  [DefaultPartition] New cluster view for partition 
> DefaultPartition (id: 2, delta: -1) : [127.0.0.2:1099]
> 13:23:58,275 INFO  [MessagingPostOffice] JBoss Messaging is failing over 
> for failed node 0. If there are many messages to reload this may take 
> some time...
> 13:23:58,442 INFO  [DefaultPartition] I am (127.0.0.2:1099) received 
> membershipChanged event:
> 13:23:58,442 INFO  [DefaultPartition] Dead members: 1 ([127.0.0.1:1099])
> 13:23:58,442 INFO  [DefaultPartition] New Members : 0 ([])
> 13:23:58,442 INFO  [DefaultPartition] All Members : 1 ([127.0.0.2:1099])
> 13:23:58,581 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|2] [127.0.0.2:42088]
> 13:23:58,620 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|2] [127.0.0.2:42088]
> 13:24:00,260 WARN  [GMS] 127.0.0.2:42088 failed to collect all ACKs (1) 
> for mcasted view [127.0.0.2:42088|2] [127.0.0.2:42088] after 2000ms, 
> missing ACKs from [127.0.0.2:42088] (received=[]), 
> local_addr=127.0.0.2:42088
> 13:24:00,661 INFO  [MessagingPostOffice] JBoss Messaging failover completed
> 13:24:00,662 INFO  [GroupMember] Dead members: 1 ([127.0.0.1:40089])
> 13:24:00,662 INFO  [GroupMember] All Members : 1 ([127.0.0.2:42088])
> 4) At some point the suspected node realizes it is suspected and the 4 
> UDP channels decide to reconnect, two at about the same time and the 
> other two w/in 55 ms of the first two:
> 13:24:39,294 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,295 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,315 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,339 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,359 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,360 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,380 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 5) This is where things break down.  It looks like one of the 4 channels 
> is able to get a local_addr, but the others get null. Perhaps a 
> concurrency bug in Configurator.startProtocolStack? (Note the first 2 
> lines below have to do with the independent TCP channel used by JBM; I 
> post them for completeness.)
> 13:24:39,568 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:39,959 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:40,833 WARN  [GMS]
> 13:24:40,834 WARN  [GMS]
> 13:24:41,362 INFO  [STDOUT]
> ---------------------------------------------------------
> GMS: address is 127.0.0.1:56000 (cluster=DefaultPartition-SFSBCache)
> ---------------------------------------------------------
> 13:24:41,362 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,488 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|3] [127.0.0.2:42088, 127.0.0.1:56000]
> 13:24:41,564 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,564 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,927 INFO  [LegacyStateTransferIntegrator] Using version 4096
> 13:24:45,941 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
> 13:24:45,993 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:7900, 127.0.0.1:7900]
> 13:24:45,995 WARN  [GMS] merge was supposed to be cancelled at merge 
> participant 127.0.0.1:7900 (merge_id=[127.0.0.1:7900|1246037080987]), 
> but it is not since merge ids do not match
> 13:24:46,029 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
> 13:24:46,029 WARN  [GMS] resume([127.0.0.1:40089|1246037080833]) does 
> not match null
> 6) Thereafter, there is continual looping of the CloserThread as it 
> tries to connect a channel, fails due to local_addr == null, waits 1 sec 
> and tries again, which goes on for hours:
> 13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> As I said, I suspect a concurrency issue that's resulting in one channel 
> getting a local_addr but thereafter others with the same shared 
> transport get null.
> Hmm, just noticed: the looping in #6 above repeats every 30 secs, not 
> every second. Which is the timeout in JChannel.startStack() :
> /* Wait LOCAL_ADDR_TIMEOUT milliseconds for local_addr to have a 
> non-null value (set by SET_LOCAL_ADDRESS) */
> local_addr=local_addr_promise.getResult(LOCAL_ADDR_TIMEOUT);
> if(local_addr == null) {
>      log.fatal("local_addr is null; cannot connect");
>      throw new ChannelException("local_addr is null");
> }
> So, seems the recurring problem is local_addr_promise isn't getting set, 
> not that it is getting set, but with a null value. *However* the *first* 
> set of FATAL logging occurs just a couple seconds after GMS logs it is 
> going to reconnect. So that first issue where local_addr == null is not 
> due to a timeout.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 10:19:51 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 1 Jul 2009 10:19:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1006) Shared transport:
 shunned multiple channels can not reconnect
In-Reply-To: <1360522755.1246439551381.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <287884442.1246457991632.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Blagojevic resolved JGRP-1006.
---------------------------------------

    Resolution: Done


Resolved on BRANCH 2.6 for 2.6.11 release

> Shared transport: shunned multiple channels can not reconnect 
> --------------------------------------------------------------
>
>                 Key: JGRP-1006
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1006
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6
>            Reporter: Vladimir Blagojevic
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11
>
>
> Brian Stansberry said:
> One of the EJB3/AS integration testsuite runs hit a JGroups problem last 
> night. *Looks like* some issue between the two AS nodes (127.0.0.1 and 
> 127.0.0.2) in the test caused the channels in one node to be 
> suspected/reconnect. Which didn't go well -- which is the subject of 
> this thread.
> I have the server logs from both, which record at INFO or above; if 
> anyone wants them, ping me. Here are the highlights:
> 1) Both nodes connect 4 channels as part of AS startup: 3 using a shared 
> transport UDP stack (for JBC, HAPartition, JBM) and one TCP one for JBM.
> 2) A bunch of test cases then execute, each deploys an EJB3 jar on each 
> node in turn, which in turn causes another JBC channel to be created and 
> connect at test start and disconnect and close at test end. This channel 
> uses the same shared  transport as the other 3, so now there are four 
> channels using that shared transport.
> 3) This create/close cycle continues a while, until on one node there is 
> some issue that results in one of the 4 UDP channels suspecting its peer 
> and all 4 UDP channels getting a new view:
> 13:23:58,150 INFO  [DefaultPartition] Suspected member: 127.0.0.1:40089
> 13:23:58,257 INFO  [GroupMember] 
> org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 4cfcb4de 
> got new view [127.0.0.2:42088|2] [127.0.0.2:42088], old view is 
> [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088]
> 13:23:58,257 INFO  [GroupMember] I am (127.0.0.2:42088)
> 13:23:58,265 INFO  [DefaultPartition] New cluster view for partition 
> DefaultPartition (id: 2, delta: -1) : [127.0.0.2:1099]
> 13:23:58,275 INFO  [MessagingPostOffice] JBoss Messaging is failing over 
> for failed node 0. If there are many messages to reload this may take 
> some time...
> 13:23:58,442 INFO  [DefaultPartition] I am (127.0.0.2:1099) received 
> membershipChanged event:
> 13:23:58,442 INFO  [DefaultPartition] Dead members: 1 ([127.0.0.1:1099])
> 13:23:58,442 INFO  [DefaultPartition] New Members : 0 ([])
> 13:23:58,442 INFO  [DefaultPartition] All Members : 1 ([127.0.0.2:1099])
> 13:23:58,581 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|2] [127.0.0.2:42088]
> 13:23:58,620 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|2] [127.0.0.2:42088]
> 13:24:00,260 WARN  [GMS] 127.0.0.2:42088 failed to collect all ACKs (1) 
> for mcasted view [127.0.0.2:42088|2] [127.0.0.2:42088] after 2000ms, 
> missing ACKs from [127.0.0.2:42088] (received=[]), 
> local_addr=127.0.0.2:42088
> 13:24:00,661 INFO  [MessagingPostOffice] JBoss Messaging failover completed
> 13:24:00,662 INFO  [GroupMember] Dead members: 1 ([127.0.0.1:40089])
> 13:24:00,662 INFO  [GroupMember] All Members : 1 ([127.0.0.2:42088])
> 4) At some point the suspected node realizes it is suspected and the 4 
> UDP channels decide to reconnect, two at about the same time and the 
> other two w/in 55 ms of the first two:
> 13:24:39,294 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,295 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,315 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,339 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,359 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,360 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,380 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 5) This is where things break down.  It looks like one of the 4 channels 
> is able to get a local_addr, but the others get null. Perhaps a 
> concurrency bug in Configurator.startProtocolStack? (Note the first 2 
> lines below have to do with the independent TCP channel used by JBM; I 
> post them for completeness.)
> 13:24:39,568 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:39,959 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:40,833 WARN  [GMS]
> 13:24:40,834 WARN  [GMS]
> 13:24:41,362 INFO  [STDOUT]
> ---------------------------------------------------------
> GMS: address is 127.0.0.1:56000 (cluster=DefaultPartition-SFSBCache)
> ---------------------------------------------------------
> 13:24:41,362 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,488 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|3] [127.0.0.2:42088, 127.0.0.1:56000]
> 13:24:41,564 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,564 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,927 INFO  [LegacyStateTransferIntegrator] Using version 4096
> 13:24:45,941 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
> 13:24:45,993 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:7900, 127.0.0.1:7900]
> 13:24:45,995 WARN  [GMS] merge was supposed to be cancelled at merge 
> participant 127.0.0.1:7900 (merge_id=[127.0.0.1:7900|1246037080987]), 
> but it is not since merge ids do not match
> 13:24:46,029 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
> 13:24:46,029 WARN  [GMS] resume([127.0.0.1:40089|1246037080833]) does 
> not match null
> 6) Thereafter, there is continual looping of the CloserThread as it 
> tries to connect a channel, fails due to local_addr == null, waits 1 sec 
> and tries again, which goes on for hours:
> 13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> As I said, I suspect a concurrency issue that's resulting in one channel 
> getting a local_addr but thereafter others with the same shared 
> transport get null.
> Hmm, just noticed: the looping in #6 above repeats every 30 secs, not 
> every second. Which is the timeout in JChannel.startStack() :
> /* Wait LOCAL_ADDR_TIMEOUT milliseconds for local_addr to have a 
> non-null value (set by SET_LOCAL_ADDRESS) */
> local_addr=local_addr_promise.getResult(LOCAL_ADDR_TIMEOUT);
> if(local_addr == null) {
>      log.fatal("local_addr is null; cannot connect");
>      throw new ChannelException("local_addr is null");
> }
> So, seems the recurring problem is local_addr_promise isn't getting set, 
> not that it is getting set, but with a null value. *However* the *first* 
> set of FATAL logging occurs just a couple seconds after GMS logs it is 
> going to reconnect. So that first issue where local_addr == null is not 
> due to a timeout.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 05:12:31 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 1 Jul 2009 05:12:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1006) Shared transport:
 shunned multiple channels can not reconnect
Message-ID: <1360522755.1246439551381.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Shared transport: shunned multiple channels can not reconnect 
--------------------------------------------------------------

                 Key: JGRP-1006
                 URL: https://jira.jboss.org/jira/browse/JGRP-1006
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.6
            Reporter: Vladimir Blagojevic
            Assignee: Vladimir Blagojevic
             Fix For: 2.6.11


Brian Stansberry said:

One of the EJB3/AS integration testsuite runs hit a JGroups problem last 
night. *Looks like* some issue between the two AS nodes (127.0.0.1 and 
127.0.0.2) in the test caused the channels in one node to be 
suspected/reconnect. Which didn't go well -- which is the subject of 
this thread.

I have the server logs from both, which record at INFO or above; if 
anyone wants them, ping me. Here are the highlights:

1) Both nodes connect 4 channels as part of AS startup: 3 using a shared 
transport UDP stack (for JBC, HAPartition, JBM) and one TCP one for JBM.

2) A bunch of test cases then execute, each deploys an EJB3 jar on each 
node in turn, which in turn causes another JBC channel to be created and 
connect at test start and disconnect and close at test end. This channel 
uses the same shared  transport as the other 3, so now there are four 
channels using that shared transport.

3) This create/close cycle continues a while, until on one node there is 
some issue that results in one of the 4 UDP channels suspecting its peer 
and all 4 UDP channels getting a new view:

13:23:58,150 INFO  [DefaultPartition] Suspected member: 127.0.0.1:40089
13:23:58,257 INFO  [GroupMember] 
org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 4cfcb4de 
got new view [127.0.0.2:42088|2] [127.0.0.2:42088], old view is 
[127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088]
13:23:58,257 INFO  [GroupMember] I am (127.0.0.2:42088)
13:23:58,265 INFO  [DefaultPartition] New cluster view for partition 
DefaultPartition (id: 2, delta: -1) : [127.0.0.2:1099]
13:23:58,275 INFO  [MessagingPostOffice] JBoss Messaging is failing over 
for failed node 0. If there are many messages to reload this may take 
some time...
13:23:58,442 INFO  [DefaultPartition] I am (127.0.0.2:1099) received 
membershipChanged event:
13:23:58,442 INFO  [DefaultPartition] Dead members: 1 ([127.0.0.1:1099])
13:23:58,442 INFO  [DefaultPartition] New Members : 0 ([])
13:23:58,442 INFO  [DefaultPartition] All Members : 1 ([127.0.0.2:1099])
13:23:58,581 INFO  [RPCManagerImpl] Received new cluster view: 
[127.0.0.2:42088|2] [127.0.0.2:42088]
13:23:58,620 INFO  [RPCManagerImpl] Received new cluster view: 
[127.0.0.2:42088|2] [127.0.0.2:42088]
13:24:00,260 WARN  [GMS] 127.0.0.2:42088 failed to collect all ACKs (1) 
for mcasted view [127.0.0.2:42088|2] [127.0.0.2:42088] after 2000ms, 
missing ACKs from [127.0.0.2:42088] (received=[]), 
local_addr=127.0.0.2:42088
13:24:00,661 INFO  [MessagingPostOffice] JBoss Messaging failover completed
13:24:00,662 INFO  [GroupMember] Dead members: 1 ([127.0.0.1:40089])
13:24:00,662 INFO  [GroupMember] All Members : 1 ([127.0.0.2:42088])

4) At some point the suspected node realizes it is suspected and the 4 
UDP channels decide to reconnect, two at about the same time and the 
other two w/in 55 ms of the first two:

13:24:39,294 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
SUSPECT message and sending back a HEARTBEAT_ACK
13:24:39,295 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
SUSPECT message and sending back a HEARTBEAT_ACK
13:24:39,315 ERROR [ConnectionTable] failed sending data to 
127.0.0.2:7900: java.net.SocketException: Broken pipe
13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
[127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
[127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
13:24:39,339 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
[127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
13:24:39,359 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
SUSPECT message and sending back a HEARTBEAT_ACK
13:24:39,360 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
SUSPECT message and sending back a HEARTBEAT_ACK
13:24:39,380 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
[127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])


5) This is where things break down.  It looks like one of the 4 channels 
is able to get a local_addr, but the others get null. Perhaps a 
concurrency bug in Configurator.startProtocolStack? (Note the first 2 
lines below have to do with the independent TCP channel used by JBM; I 
post them for completeness.)

13:24:39,568 ERROR [ConnectionTable] failed sending data to 
127.0.0.2:7900: java.net.SocketException: Broken pipe
13:24:39,959 ERROR [ConnectionTable] failed sending data to 
127.0.0.2:7900: java.net.SocketException: Broken pipe
13:24:40,833 WARN  [GMS]
13:24:40,834 WARN  [GMS]
13:24:41,362 INFO  [STDOUT]
---------------------------------------------------------
GMS: address is 127.0.0.1:56000 (cluster=DefaultPartition-SFSBCache)
---------------------------------------------------------
13:24:41,362 FATAL [JChannel] local_addr is null; cannot connect
13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
org.jgroups.ChannelException: local_addr is null
	at org.jgroups.JChannel.startStack(JChannel.java:1631)
	at org.jgroups.JChannel.connect(JChannel.java:366)
	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
org.jgroups.ChannelException: local_addr is null
	at org.jgroups.JChannel.startStack(JChannel.java:1631)
	at org.jgroups.JChannel.connect(JChannel.java:366)
	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
13:24:41,488 INFO  [RPCManagerImpl] Received new cluster view: 
[127.0.0.2:42088|3] [127.0.0.2:42088, 127.0.0.1:56000]
13:24:41,564 FATAL [JChannel] local_addr is null; cannot connect
13:24:41,564 ERROR [JChannel] failure reconnecting to channel, retrying
org.jgroups.ChannelException: local_addr is null
	at org.jgroups.JChannel.startStack(JChannel.java:1631)
	at org.jgroups.JChannel.connect(JChannel.java:366)
	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
13:24:41,927 INFO  [LegacyStateTransferIntegrator] Using version 4096
13:24:45,941 WARN  [GMS] Merge aborted. Merge leader did not get 
MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
13:24:45,993 WARN  [GMS] Merge aborted. Merge leader did not get 
MergeData from all subgroup coordinators [127.0.0.2:7900, 127.0.0.1:7900]
13:24:45,995 WARN  [GMS] merge was supposed to be cancelled at merge 
participant 127.0.0.1:7900 (merge_id=[127.0.0.1:7900|1246037080987]), 
but it is not since merge ids do not match
13:24:46,029 WARN  [GMS] Merge aborted. Merge leader did not get 
MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
13:24:46,029 WARN  [GMS] resume([127.0.0.1:40089|1246037080833]) does 
not match null

6) Thereafter, there is continual looping of the CloserThread as it 
tries to connect a channel, fails due to local_addr == null, waits 1 sec 
and tries again, which goes on for hours:

13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
org.jgroups.ChannelException: local_addr is null
	at org.jgroups.JChannel.startStack(JChannel.java:1631)
	at org.jgroups.JChannel.connect(JChannel.java:366)
	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)


As I said, I suspect a concurrency issue that's resulting in one channel 
getting a local_addr but thereafter others with the same shared 
transport get null.

Hmm, just noticed: the looping in #6 above repeats every 30 secs, not 
every second. Which is the timeout in JChannel.startStack() :

/* Wait LOCAL_ADDR_TIMEOUT milliseconds for local_addr to have a 
non-null value (set by SET_LOCAL_ADDRESS) */
local_addr=local_addr_promise.getResult(LOCAL_ADDR_TIMEOUT);
if(local_addr == null) {
     log.fatal("local_addr is null; cannot connect");
     throw new ChannelException("local_addr is null");
}

So, seems the recurring problem is local_addr_promise isn't getting set, 
not that it is getting set, but with a null value. *However* the *first* 
set of FATAL logging occurs just a couple seconds after GMS logs it is 
going to reconnect. So that first issue where local_addr == null is not 
due to a timeout.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 10:15:52 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Wed, 1 Jul 2009 10:15:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1006) Shared transport:
 shunned multiple channels can not reconnect
In-Reply-To: <1360522755.1246439551381.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1586032072.1246457752044.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474459#action_12474459 ] 

Vladimir Blagojevic commented on JGRP-1006:
-------------------------------------------

Added test method: SharedTransportTest#testShunReconnect()

> Shared transport: shunned multiple channels can not reconnect 
> --------------------------------------------------------------
>
>                 Key: JGRP-1006
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1006
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6
>            Reporter: Vladimir Blagojevic
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11
>
>
> Brian Stansberry said:
> One of the EJB3/AS integration testsuite runs hit a JGroups problem last 
> night. *Looks like* some issue between the two AS nodes (127.0.0.1 and 
> 127.0.0.2) in the test caused the channels in one node to be 
> suspected/reconnect. Which didn't go well -- which is the subject of 
> this thread.
> I have the server logs from both, which record at INFO or above; if 
> anyone wants them, ping me. Here are the highlights:
> 1) Both nodes connect 4 channels as part of AS startup: 3 using a shared 
> transport UDP stack (for JBC, HAPartition, JBM) and one TCP one for JBM.
> 2) A bunch of test cases then execute, each deploys an EJB3 jar on each 
> node in turn, which in turn causes another JBC channel to be created and 
> connect at test start and disconnect and close at test end. This channel 
> uses the same shared  transport as the other 3, so now there are four 
> channels using that shared transport.
> 3) This create/close cycle continues a while, until on one node there is 
> some issue that results in one of the 4 UDP channels suspecting its peer 
> and all 4 UDP channels getting a new view:
> 13:23:58,150 INFO  [DefaultPartition] Suspected member: 127.0.0.1:40089
> 13:23:58,257 INFO  [GroupMember] 
> org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 4cfcb4de 
> got new view [127.0.0.2:42088|2] [127.0.0.2:42088], old view is 
> [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088]
> 13:23:58,257 INFO  [GroupMember] I am (127.0.0.2:42088)
> 13:23:58,265 INFO  [DefaultPartition] New cluster view for partition 
> DefaultPartition (id: 2, delta: -1) : [127.0.0.2:1099]
> 13:23:58,275 INFO  [MessagingPostOffice] JBoss Messaging is failing over 
> for failed node 0. If there are many messages to reload this may take 
> some time...
> 13:23:58,442 INFO  [DefaultPartition] I am (127.0.0.2:1099) received 
> membershipChanged event:
> 13:23:58,442 INFO  [DefaultPartition] Dead members: 1 ([127.0.0.1:1099])
> 13:23:58,442 INFO  [DefaultPartition] New Members : 0 ([])
> 13:23:58,442 INFO  [DefaultPartition] All Members : 1 ([127.0.0.2:1099])
> 13:23:58,581 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|2] [127.0.0.2:42088]
> 13:23:58,620 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|2] [127.0.0.2:42088]
> 13:24:00,260 WARN  [GMS] 127.0.0.2:42088 failed to collect all ACKs (1) 
> for mcasted view [127.0.0.2:42088|2] [127.0.0.2:42088] after 2000ms, 
> missing ACKs from [127.0.0.2:42088] (received=[]), 
> local_addr=127.0.0.2:42088
> 13:24:00,661 INFO  [MessagingPostOffice] JBoss Messaging failover completed
> 13:24:00,662 INFO  [GroupMember] Dead members: 1 ([127.0.0.1:40089])
> 13:24:00,662 INFO  [GroupMember] All Members : 1 ([127.0.0.2:42088])
> 4) At some point the suspected node realizes it is suspected and the 4 
> UDP channels decide to reconnect, two at about the same time and the 
> other two w/in 55 ms of the first two:
> 13:24:39,294 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,295 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,315 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,339 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,359 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,360 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,380 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 5) This is where things break down.  It looks like one of the 4 channels 
> is able to get a local_addr, but the others get null. Perhaps a 
> concurrency bug in Configurator.startProtocolStack? (Note the first 2 
> lines below have to do with the independent TCP channel used by JBM; I 
> post them for completeness.)
> 13:24:39,568 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:39,959 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:40,833 WARN  [GMS]
> 13:24:40,834 WARN  [GMS]
> 13:24:41,362 INFO  [STDOUT]
> ---------------------------------------------------------
> GMS: address is 127.0.0.1:56000 (cluster=DefaultPartition-SFSBCache)
> ---------------------------------------------------------
> 13:24:41,362 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,488 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|3] [127.0.0.2:42088, 127.0.0.1:56000]
> 13:24:41,564 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,564 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,927 INFO  [LegacyStateTransferIntegrator] Using version 4096
> 13:24:45,941 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
> 13:24:45,993 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:7900, 127.0.0.1:7900]
> 13:24:45,995 WARN  [GMS] merge was supposed to be cancelled at merge 
> participant 127.0.0.1:7900 (merge_id=[127.0.0.1:7900|1246037080987]), 
> but it is not since merge ids do not match
> 13:24:46,029 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
> 13:24:46,029 WARN  [GMS] resume([127.0.0.1:40089|1246037080833]) does 
> not match null
> 6) Thereafter, there is continual looping of the CloserThread as it 
> tries to connect a channel, fails due to local_addr == null, waits 1 sec 
> and tries again, which goes on for hours:
> 13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> As I said, I suspect a concurrency issue that's resulting in one channel 
> getting a local_addr but thereafter others with the same shared 
> transport get null.
> Hmm, just noticed: the looping in #6 above repeats every 30 secs, not 
> every second. Which is the timeout in JChannel.startStack() :
> /* Wait LOCAL_ADDR_TIMEOUT milliseconds for local_addr to have a 
> non-null value (set by SET_LOCAL_ADDRESS) */
> local_addr=local_addr_promise.getResult(LOCAL_ADDR_TIMEOUT);
> if(local_addr == null) {
>      log.fatal("local_addr is null; cannot connect");
>      throw new ChannelException("local_addr is null");
> }
> So, seems the recurring problem is local_addr_promise isn't getting set, 
> not that it is getting set, but with a null value. *However* the *first* 
> set of FATAL logging occurs just a couple seconds after GMS logs it is 
> going to reconnect. So that first issue where local_addr == null is not 
> due to a timeout.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 19:34:51 2009
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Wed, 1 Jul 2009 19:34:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1126790880.1246491291503.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474526#action_12474526 ] 

Richard Kennard commented on JBMETA-208:
----------------------------------------

Thank you all for the time and thought you have put into this. I think everybody's position is very reasonable. In particular, I understand...

"When a JAR is deployed, we first look whether there is an ejb-jar.xml. And if it's there we can tell by its version which EJB version this deployment is. And if it's EJB2 then does it make sense to look into each class in the JAR to make sure there are no EJB3 annotations? Because this is what you are asking for. It's rather expensive performance-wise."

At the same time, though, I would counsel that "the deployment should have been completely skipped from the EJB3 processing", without any warning, is rather dangerous. Even though the EJB 3.0 spec might mandate "all EJB deployment descriptors must indicate the ejb-jar schema by using the Java EE namespace" plenty of examples and tutorials on the Web, for reasons of brevity or simply laziness, omit it. For example:

http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html

You can fix the JBoss ones, but not all the third-party ones. If I may humbly suggest a solution:

1. Scan the ejb-jar.xml
2. If it contains a DTD, treat it as EJB 2.x (or 1.x) and don't scan for annotations
3. If it contains a namespace, treat it as EJB 3.x (or above) and scan for annotations
4. If it contains neither a DTD nor a namespace, display a warning that you are entering 'compatibility mode' where you both process the ejb-jar.xml and scan for annotations (at the expense of reduced startup time). The warning should advise the developer 'either add a DTD or a namespace to avoid this warning'

In some ways this is more accurate, because if there is no DTD or namespace you really can't say what version it is.

Regards,

Richard.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <ejb-jar version="3.0"
>     xmlns="http://java.sun.com/xml/ns/javaee"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  1 23:56:51 2009
From: jira-events at lists.jboss.org (deckrider deckrider (JIRA))
Date: Wed, 1 Jul 2009 23:56:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-1121) Client
 SocketFactory should be configurable by InvokerLocator
In-Reply-To: <31741702.1239943414266.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <407884410.1246507011505.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBREM-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474528#action_12474528 ] 

deckrider deckrider commented on JBREM-1121:
--------------------------------------------

I'm trying to understand how this new mechanism works.  It seems that adding org.jboss.remoting.serverAuthMode=false" to the EJB3 InvokerLocator.

Before remoting 2.2.3 I was using socketFactoryClassName=some.package.MySocketFactory as per http://www.jboss.org/index.html?module=bb&op=viewtopic&t=153111 but replacing that with serverAuthMode=false isn't working.

I also tried useAllParams=true (as per the docs) but that didn't seem to help either.  And I'm not sure what do do about configOverridesLocator or whether thats having any effect.

> Client SocketFactory should be configurable by InvokerLocator
> -------------------------------------------------------------
>
>                 Key: JBREM-1121
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1121
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.2.SP11, 2.5.1 (Flounder)
>            Reporter: Ron Sigal
>            Assignee: Ron Sigal
>             Fix For: 2.2.3, 2.5.2 (Flounder)
>
>
> org.jboss.remoting.RemoteClientInvoker, which creates the client invoker's SocketFactory, uses only the parameters passed in the configuration map (except for looking in the InvokerLocator for org.jboss.remoting.SOCKET_FACTORY_CLASS_NAME (actual value "socketFactoryClassName"), which was introduced in JBREM-1014 "Support injection of socket factory class name into AbstractInvoker").  There should be a configurable option to use all parameters from the InvokerLocator.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 02:46:51 2009
From: jira-events at lists.jboss.org (Colin Mondesir (JIRA))
Date: Thu, 2 Jul 2009 02:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-1139) Modify PortUtil to
 allow a
 configurable range for MIN_UNPRIVILEGED_PORT and MAX_LEGAL_PORT.
Message-ID: <215395097.1246517211483.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Modify PortUtil to allow a configurable range for MIN_UNPRIVILEGED_PORT and MAX_LEGAL_PORT.
-------------------------------------------------------------------------------------------

                 Key: JBREM-1139
                 URL: https://jira.jboss.org/jira/browse/JBREM-1139
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.2.SP8
            Reporter: Colin Mondesir


PortUtil could be improved to read the port range configuration.
This is straightforward and no side effect is expected.  However,
PortUtil and its callers will need some refactoring as it is just a
static utility classes currently.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 03:46:03 2009
From: jira-events at lists.jboss.org (francesco dicarlo (JIRA))
Date: Thu, 2 Jul 2009 03:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (BPEL-306) Variable Instances
 translation
 funcionality(From MessageValue to simple types like String,Integer,Long)
Message-ID: <2123265903.1246520763456.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Variable Instances translation funcionality(From MessageValue to simple types like String,Integer,Long)
-------------------------------------------------------------------------------------------------------

                 Key: BPEL-306
                 URL: https://jira.jboss.org/jira/browse/BPEL-306
             Project: JBoss jBPM BPEL
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Engine
    Affects Versions: jBPM BPEL 1.1.1
         Environment: Jboss 4.2.3.GA
JBPM-BPEL 1.1.1
            Reporter: francesco dicarlo
            Assignee: Alejandro Guizar


Would be good to have a functionality (i.e. a Translator) to automatically translate VariableInstance that in JBPM-BPEL are of type MessageValue into the simple type that were defined in the workflow.

The use of this code \\Map varsMap=instance.getContextInstance().getVariables();\\ returns a Map with key the name of the variable but with value a type MessageValue that can't be translated automatically for all the workflow because rely on workflow implementation and design.







-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 03:47:53 2009
From: jira-events at lists.jboss.org (francesco dicarlo (JIRA))
Date: Thu, 2 Jul 2009 03:47:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-306) Variable Instances
 translation
 funcionality(From MessageValue to simple types like String,Integer,Long)
In-Reply-To: <2123265903.1246520763456.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1168253862.1246520873174.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/BPEL-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

francesco dicarlo updated BPEL-306:
-----------------------------------

    Description: 
Would be good to have a functionality (i.e. a Translator) to automatically translate VariableInstance that in JBPM-BPEL are of type MessageValue into the simple type that were defined in the workflow.

The use of this code \\Map varsMap=instance.getContextInstance().getVariables();\\ returns a Map with key the name of the variable but with value a type MessageValue that can't be translated automatically for all the workflow because relies on workflow implementation and design.







  was:
Would be good to have a functionality (i.e. a Translator) to automatically translate VariableInstance that in JBPM-BPEL are of type MessageValue into the simple type that were defined in the workflow.

The use of this code \\Map varsMap=instance.getContextInstance().getVariables();\\ returns a Map with key the name of the variable but with value a type MessageValue that can't be translated automatically for all the workflow because rely on workflow implementation and design.







         Labels: bpel jbpm-bpel   (was: )


> Variable Instances translation funcionality(From MessageValue to simple types like String,Integer,Long)
> -------------------------------------------------------------------------------------------------------
>
>                 Key: BPEL-306
>                 URL: https://jira.jboss.org/jira/browse/BPEL-306
>             Project: JBoss jBPM BPEL
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1.1
>         Environment: Jboss 4.2.3.GA
> JBPM-BPEL 1.1.1
>            Reporter: francesco dicarlo
>            Assignee: Alejandro Guizar
>
> Would be good to have a functionality (i.e. a Translator) to automatically translate VariableInstance that in JBPM-BPEL are of type MessageValue into the simple type that were defined in the workflow.
> The use of this code \\Map varsMap=instance.getContextInstance().getVariables();\\ returns a Map with key the name of the variable but with value a type MessageValue that can't be translated automatically for all the workflow because relies on workflow implementation and design.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 05:43:52 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 2 Jul 2009 05:43:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7029) Test
 org.jboss.test.profileservice.test.PlatformMBeanUnitTestCase(profileservice).testThreadMXBean
 fails on JDK6
In-Reply-To: <9161934.1245234836800.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1856092146.1246527832056.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber reassigned JBAS-7029:
-----------------------------------------

    Assignee: Emanuel Muckenhuber  (was: Shelly McGowan)


> Test org.jboss.test.profileservice.test.PlatformMBeanUnitTestCase(profileservice).testThreadMXBean fails on JDK6
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7029
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7029
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows and Linux 
> JDK6
>            Reporter: Pavel Slavicek
>            Assignee: Emanuel Muckenhuber
>
> Test org.jboss.test.profileservice.test.PlatformMBeanUnitTestCase(profileservice).testThreadMXBean fails on JDK6 on line 
>       Set<ManagedOperation> ops = mo.getOperations();
>       log.debug(ops);
>       assertEquals("Ops count is 8", 8, ops.size());
> JDK6 contains JMX 1.4 and ThreadMXBean has 11 operations.
> Test log:
> junit.framework.AssertionFailedError: Ops count is 8 expected:&lt;8&gt; but was:&lt;11&gt;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 07:17:51 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 2 Jul 2009 07:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-77)
 ClassFile.renameClass(s) is not
 processing the LocalVariableAttributes
In-Reply-To: <16184693.1238601682880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1994600823.1246533471654.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-77.
----------------------------------

    Fix Version/s: 3.11.0.GA
       Resolution: Done


fixed this bug.

> ClassFile.renameClass(s) is not processing the LocalVariableAttributes
> ----------------------------------------------------------------------
>
>                 Key: JASSIST-77
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-77
>             Project: Javassist
>          Issue Type: Bug
>            Reporter: Adrian Brock
>            Assignee: Shigeru Chiba
>             Fix For: 3.11.0.GA
>
>
> ClassFile.renameClass(s) is not changing the descriptor indexes for LocalVariableAttributes.
> This means the types of local variables are not getting updated.
> See the forum thread for an example.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 07:52:51 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Thu, 2 Jul 2009 07:52:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1007) Flush: change
 signature of JChannel#startFlush to include checked exception
Message-ID: <2067196155.1246535571473.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Flush: change signature of JChannel#startFlush to include checked exception
---------------------------------------------------------------------------

                 Key: JGRP-1007
                 URL: https://jira.jboss.org/jira/browse/JGRP-1007
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.6, 2.8
            Reporter: Vladimir Blagojevic
            Assignee: Vladimir Blagojevic
             Fix For: 3.0


We have to change signature of startFlush method to include checked exceptions in its signature. We have previously relied on boolean return value of startFlush to get information about success of startFlush method invocation. This approach has been proven to be insufficient, particularly in the light of dealing with [JGRP-985]. We need to discriminate various reasons why startFlush failed, i.e due flush collision, missing response from flush member and so on. Therefore, starting with release 3.0 startFlush method will be void and will throw checked exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 07:59:04 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 2 Jul 2009 07:59:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1861) Upgrade
 microcontainer to 2.0.8.GA
Message-ID: <2037967472.1246535944178.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade microcontainer to 2.0.8.GA
----------------------------------

                 Key: EJBTHREE-1861
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1861
             Project: EJB 3.0
          Issue Type: Thirdparty Change
    Affects Versions: 1.1.8
            Reporter: jaikiran pai
            Assignee: jaikiran pai


In order to be able to use the @DisableAOP feature in MC, we need to upgrade to this latest version of MC. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 08:10:51 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Thu, 2 Jul 2009 08:10:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-985) Flush and join
 problems during constant node failures and constant joins
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1205450929.1246536651451.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Blagojevic resolved JGRP-985.
--------------------------------------

    Resolution: Won't Fix


While we acknowledge that this issue is possible we are confident that it is highly unlikely to occur in normal range of operations. We have added a unit test FlushWithChannelJoinsAndFailuresTest in an attempt to capture the scenario you describe while we have concluded that we can deal with similar cases a bit better in the upcoming releases. Therefore, we have opened [JGRP-1007] as a continuation of flush issues first discovered in this case.   

> Flush and join problems during constant node failures and constant joins
> ------------------------------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 08:14:52 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Thu, 2 Jul 2009 08:14:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <105167905.1246536892464.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474602#action_12474602 ] 

Victor N commented on JGRP-1003:
--------------------------------

I will check how it works now.
By the way, I would recommend to set use_send_queues="true" in the default tcp.xml in JGroups sources/examples!

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 08:18:51 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 2 Jul 2009 08:18:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-215) Allow for
 configuration of transaction-retry
Message-ID: <950768065.1246537131938.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Allow for configuration of transaction-retry
--------------------------------------------

                 Key: JBMETA-215
                 URL: https://jira.jboss.org/jira/browse/JBMETA-215
             Project: JBoss Metadata
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf
             Fix For: 1.0.2.Beta2, 2.0.0.CR1


The @TransactionRetry annotation must have an equivalent configuration option in descriptors.

@TransactionRetry(numRetries=4, waitTime=1, waitTimeUnit=TimeUnit.SECONDS) 

<assembly-descriptor>
  <transaction-retry>
    <!-- bindings as per spec -->
    <method>
      <ejb-name>*</ejb-name>
      <method-name>...</method-name>
    </method>
    ...
    <num-retries>4</num-retries>
    <wait-time>1</wait-time>
    <wait-time-unit>SECONDS</wait-time-unit>
  </transaction-retry>
</assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 08:22:52 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 2 Jul 2009 08:22:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1499536855.1246537372929.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474608#action_12474608 ] 

Bela Ban commented on JGRP-1003:
--------------------------------

set use_send_queue="true" in all TCP configs

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 08:22:52 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Thu, 2 Jul 2009 08:22:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMICROCONT-446)
 bean-deployer xsds don't contain web references
In-Reply-To: <12930376.1245605276537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1977909108.1246537372718.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMICROCONT-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474607#action_12474607 ] 

Wolfgang Knauf commented on JBMICROCONT-446:
--------------------------------------------

Hi David,

after doing a bit of google, I agree with you: it seems that the parser should search for the included file in the same location as the current XSD if no full URI is specified.
A short test reveals: this seems to work for jboss_5_1.xsd and jboss-common_5_1.xsd.

The only possible problem where this might fail is when you add "bean-deployer_2_0.xsd" to your project and don't add the included "jboss-beans-common_2_0.xsd". Then Eclipse cannot find the included XSD (a similar thing happened to me some time ago while checking another validation error in jboss_5_1.xsd). 

Hopefully, the XSD files will be added to the JBoss website so that I can give them a try.

So, if you don't want to change it, you can close this issue. But I would prefer full web URIs ;-).

> bean-deployer xsds don't contain web references
> -----------------------------------------------
>
>                 Key: JBMICROCONT-446
>                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-446
>             Project: JBoss Microcontainer
>          Issue Type: Bug
>            Reporter: Wolfgang Knauf
>            Assignee: Kabir Khan
>
> bean-deployer_2_0.xsd:
>    <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">
> =>should point. 
>    <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">
> The comment for a sample instance should also contain a schema location attribute:
>          <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xmlns="urn:jboss:bean-deployer:2.0"
>             xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">
> ==================
> bean-deployer_1_0.xsd:
> The comment for a sample instance should point to the web schema location:
>          <deployment
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
>             xmlns="urn:jboss:bean-deployer">
> =================
> policy_1_0.xsd:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
> should be:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>
> =================
> bean-deployer_2_0.xsd raises validation errors in Eclipse:
> -rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
> -src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
> According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426 ), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 08:22:52 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Thu, 2 Jul 2009 08:22:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-985) Flush and join
 problems during constant node failures and constant joins
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1996112044.1246537372263.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Blagojevic updated JGRP-985:
-------------------------------------

    Comment: was deleted


> Flush and join problems during constant node failures and constant joins
> ------------------------------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 08:22:52 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Thu, 2 Jul 2009 08:22:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-985) Flush and join
 problems during constant node failures and constant joins
In-Reply-To: <19490547.1243212656656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2084107928.1246537372552.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474606#action_12474606 ] 

Vladimir Blagojevic commented on JGRP-985:
------------------------------------------

While we acknowledge that this issue is possible we are confident that it is highly unlikely to occur in normal range of operations. We have added a unit test FlushWithChannelJoinsAndFailuresTest in an attempt to capture the scenario you describe. We have concluded that we can deal with similar cases a bit better in the upcoming releases. Therefore, we have opened [JGRP-1007] as a continuation of flush issues first discovered in this case. 

> Flush and join problems during constant node failures and constant joins
> ------------------------------------------------------------------------
>
>                 Key: JGRP-985
>                 URL: https://jira.jboss.org/jira/browse/JGRP-985
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3, 2.6.4, 2.6.5, 2.7
>         Environment: linux redhat 2.9.6, jdk 1.5
>            Reporter: Ronn C
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>         Attachments: jgroup.tar.gz
>
>
> I am experiencing a problem with jgroups trying to join existing cluster.  
>  
> Occasionally, new node joining a existing cluster can experience this problem. 
>  
> 2009-05-21 12:04:02,568 [main] WARN org.jgroups.protocols.pbcast.GMS:144 - join(callisto.tmca.com.au-18715) sent to callisto.tmca.com.au-8185 timed out (after 3000 ms), retrying 
>  
> Retries can varies from a couple of times to infinitely retrying. 
>  
> Debugging the code, I've discovered that before join the coordinator will perform a GMS flush and unless that GMS flush success it won't reply with a join response. 
>  
> So sure enough at the coordinator, I see this log. 
> 2009-05-21 12:05:25,902 [ViewHandler,callisto.tmca.com.au-8185] WARN org.jgroups.protocols.pbcast.GMS:749 - GMS flush by coordinator at callisto.tmca.com.au-8185 failed 
>  
> I've originally come across this problem in our prod environment with 2.6.3. I have been able to replicate it reliably with 2.6.3. I have tested with 2.7.0 and 2.8.0.alpha3 and retries still occurs but generally it would sort itself out within a minute. However, I've found that retries can still occurs infinitely on 2.8.0 if you keep repeating the test often enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 08:44:51 2009
From: jira-events at lists.jboss.org (Daniel Cullender (JIRA))
Date: Thu, 2 Jul 2009 08:44:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1676) Jboss
	Messaging deadlock
Message-ID: <317741887.1246538691801.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Jboss Messaging deadlock
------------------------

                 Key: JBMESSAGING-1676
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1676
             Project: JBoss Messaging
          Issue Type: Bug
          Components: AS Integration
    Affects Versions: 1.4.3.GA
         Environment: Version:Linux 2.6.18-53.el5
Description:Linux Operating System
Traits
OS Name: Linux
OS Version: 2.6.18-53.el5
Architecture: i386
Distribution Name: CentOS
Distribution Version: release 5 (Final)
            Reporter: Daniel Cullender
            Assignee: Tim Fox


Under high concurrent load it appears that jboss messaging gets stuck in the Hashmap.put method which causes the threads to deadlock which in turn causes transaction timeouts.

We have several mdb's which have max session sizes of 150, we have max strict pool size of 150 and the jboss thread pool size of 50.

Recently upgraded from jboss AS 4 MQ series to jboss 5 AS with jboss messaging 1.4.3.GA, with JbossMQ  this problem did not occur.

The stack trace of the problem is as follows :

Thread: WorkManager(2)-50 : priority:5, demon:true, threadId:147,
threadState:RUNNABLE
java.util.HashMap.put(HashMap.java:374)
java.util.HashSet.add(HashSet.java:200)
org.jboss.jms.client.state.HierarchicalStateSupport.(HierarchicalStateSupport.java:63)
org.jboss.jms.client.state.ProducerState.(ProducerState.java:68)
org.jboss.jms.client.container.StateCreationAspect.handleCreateProducerDelegate(StateCreationAspect.java:180)
org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateProducerDelegate_30485827.invoke(StateCreationAspect_z_handleCreateProducerDelegate_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.jms.client.delegate.ClientSessionDelegate.createProducerDelegate(ClientSessionDelegate.java)
org.jboss.jms.client.JBossSession.createProducer(JBossSession.java:209)
qut.common.dao.JmsDao.publishMessage(JmsDao.java:66)
qut.common.dao.JmsDao.publish(JmsDao.java:104)
qut.order.manager.OrderManagerMBean.publish(OrderManagerMBean.java:156)
qut.order.manager.OrderManagerMBean.process(OrderManagerMBean.java:98)
sun.reflect.GeneratedMethodAccessor354.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:451)
org.jboss.ejb3.service.ServiceMBeanDelegate.invoke(ServiceMBeanDelegate.java:215)
org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
$Proxy1543.process(Unknown Source)
qut.order.mdb.OrderManagerTradingDataMDBean.onMessage(OrderManagerTradingDataMDBean.java:64)
sun.reflect.GeneratedMethodAccessor353.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor$InvocationContext.proceed(InvocationContextInterceptor.java:138)
qut.common.interceptor.ConcurrencyInterceptor.myInterceptor(ConcurrencyInterceptor.java:46)
sun.reflect.GeneratedMethodAccessor320.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:83)
org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:70)
org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:59)
org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:80)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:282)
org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:270)
org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:140)
$Proxy389.onMessage(Unknown Source)
org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:178)
org.jboss.jms.client.container.ClientConsumer.callOnMessageStatic(ClientConsumer.java:160)
org.jboss.jms.client.container.SessionAspect.handleRun(SessionAspect.java:831)
org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleRun_30485827.invoke(SessionAspect_z_handleRun_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.jms.client.delegate.ClientSessionDelegate.run(ClientSessionDelegate.java)
org.jboss.jms.client.JBossSession.run(JBossSession.java:199)
org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:234)
org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205)
org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
java.lang.Thread.run(Thread.java:619)

Locked synchronizers : 
- locked <0x535d1e> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

Thread: WorkManager(2)-70 : priority:5, demon:true, threadId:168,
threadState:RUNNABLE
java.util.HashMap.put(HashMap.java:374)
java.util.HashSet.add(HashSet.java:200)
org.jboss.jms.client.state.HierarchicalStateSupport.(HierarchicalStateSupport.java:63)
org.jboss.jms.client.state.ProducerState.(ProducerState.java:68)
org.jboss.jms.client.container.StateCreationAspect.handleCreateProducerDelegate(StateCreationAspect.java:180)
org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateProducerDelegate_30485827.invoke(StateCreationAspect_z_handleCreateProducerDelegate_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.jms.client.delegate.ClientSessionDelegate.createProducerDelegate(ClientSessionDelegate.java)
org.jboss.jms.client.JBossSession.createProducer(JBossSession.java:209)
qut.common.dao.JmsDao.publishMessage(JmsDao.java:66)
qut.common.dao.JmsDao.publish(JmsDao.java:104)
qut.order.manager.OrderManagerMBean.publish(OrderManagerMBean.java:156)
qut.order.manager.OrderManagerMBean.process(OrderManagerMBean.java:98)
sun.reflect.GeneratedMethodAccessor354.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:451)
org.jboss.ejb3.service.ServiceMBeanDelegate.invoke(ServiceMBeanDelegate.java:215)
org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
$Proxy1384.process(Unknown Source)
qut.order.mdb.OrderManagerTradingDataMDBean.onMessage(OrderManagerTradingDataMDBean.java:64)
sun.reflect.GeneratedMethodAccessor353.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor$InvocationContext.proceed(InvocationContextInterceptor.java:138)
qut.common.interceptor.ConcurrencyInterceptor.myInterceptor(ConcurrencyInterceptor.java:46)
sun.reflect.GeneratedMethodAccessor320.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:83)
org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:70)
org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:59)
org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:80)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:282)
org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:270)
org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:140)
$Proxy389.onMessage(Unknown Source)
org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:178)
org.jboss.jms.client.container.ClientConsumer.callOnMessageStatic(ClientConsumer.java:160)
org.jboss.jms.client.container.SessionAspect.handleRun(SessionAspect.java:831)
org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleRun_30485827.invoke(SessionAspect_z_handleRun_30485827.java)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
org.jboss.jms.client.delegate.ClientSessionDelegate.run(ClientSessionDelegate.java)
org.jboss.jms.client.JBossSession.run(JBossSession.java:199)
org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:234)
org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205)
org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
java.lang.Thread.run(Thread.java:619)

Locked synchronizers : 
- locked <0x18827b6> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)





-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 09:29:51 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 2 Jul 2009 09:29:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1008) PING: remove
 functionality for accessing GossipRouters and static lists
Message-ID: <524579444.1246541391446.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

PING: remove functionality for accessing GossipRouters and static lists
-----------------------------------------------------------------------

                 Key: JGRP-1008
                 URL: https://jira.jboss.org/jira/browse/JGRP-1008
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.0


If initial_hosts is used, switch to TCPPING instead. If gossip_hosts is used, use TCPGOSSIP instead.

We can remove this (duplicate) functionality

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 09:35:51 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 2 Jul 2009 09:35:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1008) PING: remove
 functionality for accessing GossipRouters and static lists
In-Reply-To: <524579444.1246541391446.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <736773665.1246541751591.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1008:
---------------------------

    Fix Version/s: 2.8
                       (was: 3.0)


> PING: remove functionality for accessing GossipRouters and static lists
> -----------------------------------------------------------------------
>
>                 Key: JGRP-1008
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1008
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> If initial_hosts is used, switch to TCPPING instead. If gossip_hosts is used, use TCPGOSSIP instead.
> We can remove this (duplicate) functionality

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 09:40:51 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 2 Jul 2009 09:40:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1008) PING: remove
 functionality for accessing GossipRouters and static lists
In-Reply-To: <524579444.1246541391446.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1545988388.1246542051547.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1008.
----------------------------

    Resolution: Done


> PING: remove functionality for accessing GossipRouters and static lists
> -----------------------------------------------------------------------
>
>                 Key: JGRP-1008
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1008
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> If initial_hosts is used, switch to TCPPING instead. If gossip_hosts is used, use TCPGOSSIP instead.
> We can remove this (duplicate) functionality

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 09:57:51 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 2 Jul 2009 09:57:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMICROCONT-446)
 bean-deployer xsds don't contain web references
In-Reply-To: <12930376.1245605276537.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <715563072.1246543071923.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMICROCONT-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474632#action_12474632 ] 

David Lloyd commented on JBMICROCONT-446:
-----------------------------------------

Both of the XSD files are distributed together in the MC maven artifact and other distributions, so it should be easy enough to grab both files by hand at worst (with IDEA it's never had a problem finding them both).

I think all of the problems in the ticket have been addressed, but since Kabir grabbed this ticket, it's ultimately up to him whether to close it. :-)

> bean-deployer xsds don't contain web references
> -----------------------------------------------
>
>                 Key: JBMICROCONT-446
>                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-446
>             Project: JBoss Microcontainer
>          Issue Type: Bug
>            Reporter: Wolfgang Knauf
>            Assignee: Kabir Khan
>
> bean-deployer_2_0.xsd:
>    <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">
> =>should point. 
>    <xsd:redefine schemaLocation="http://www.jboss.org/j2ee/schema/jboss-beans-common_2_0.xsd">
> The comment for a sample instance should also contain a schema location attribute:
>          <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xmlns="urn:jboss:bean-deployer:2.0"
>             xsi:schemaLocation="urn:jboss:bean-deployer:2.0 http://www.jboss.org/j2ee/schema/bean-deployer_2_0.xsd">
> ==================
> bean-deployer_1_0.xsd:
> The comment for a sample instance should point to the web schema location:
>          <deployment
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="urn:jboss:bean-deployer http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"
>             xmlns="urn:jboss:bean-deployer">
> =================
> policy_1_0.xsd:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0"/>
> should be:
>    <xsd:import namespace="urn:jboss:bean-deployer:2.0" schemaLocation="http://www.jboss.org/j2ee/schema/bean-deployer_1_0.xsd"/>
> =================
> bean-deployer_2_0.xsd raises validation errors in Eclipse:
> -rcase-RecurseLax.2: There is not a complete functional mapping between the particles.	
> -src-redefine.6.2.2: Group 'valueGroup' does not properly restrict the group it redefines; constraint violated:  'rcase-RecurseLax.2'.
> According to the forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4187426 ), this might also be a bug of the validator, but I don't have enough xsd knowledge to create a Xerces bugreport.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 10:53:51 2009
From: jira-events at lists.jboss.org (Mike Conner (JIRA))
Date: Thu, 2 Jul 2009 10:53:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7071) use-try-lock option
 in data source configuration files is ignored
In-Reply-To: <329869123.1246546191859.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1409636642.1246546431897.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Conner updated JBAS-7071:
------------------------------

    Priority: Minor  (was: Major)


> use-try-lock option in data source configuration files is ignored
> -----------------------------------------------------------------
>
>                 Key: JBAS-7071
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7071
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows XP Professional V2002, service pack 3
>            Reporter: Mike Conner
>            Assignee: Jesper Pedersen
>            Priority: Minor
>
> (FYI  your "READ THIS BEFORE ENTERING NEW REPORTS" points to a  "You caught us doing a little maintenance..." page, so pardon me if I missed something in procedure. )
> The data source configuration property "use-try-lock" is effectively ignored.
> This is because the value is defined in configuration as a long, but the object that is actually set on  an
> org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory  extends 
>    org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnectionFactory
> This class defines it as taking an int, not a long:
>    public void setUseTryLock(int useTryLock)
> As such, reflection in ManagedConnectionFactoryDeployment.setManagedConnectionFactoryAttribute() does not find the method and simply logs it at a trace level, so the value never gets set.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 10:49:51 2009
From: jira-events at lists.jboss.org (Mike Conner (JIRA))
Date: Thu, 2 Jul 2009 10:49:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7071) use-try-lock option
 in data source configuration files is ignored
Message-ID: <329869123.1246546191859.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

use-try-lock option in data source configuration files is ignored
-----------------------------------------------------------------

                 Key: JBAS-7071
                 URL: https://jira.jboss.org/jira/browse/JBAS-7071
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA service
    Affects Versions: JBossAS-5.1.0.GA
         Environment: Windows XP Professional V2002, service pack 3
            Reporter: Mike Conner
            Assignee: Jesper Pedersen


(FYI  your "READ THIS BEFORE ENTERING NEW REPORTS" points to a  "You caught us doing a little maintenance..." page, so pardon me if I missed something in procedure. )

The data source configuration property "use-try-lock" is effectively ignored.
This is because the value is defined in configuration as a long, but the object that is actually set on  an

org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory  extends 
   org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnectionFactory

This class defines it as taking an int, not a long:

   public void setUseTryLock(int useTryLock)

As such, reflection in ManagedConnectionFactoryDeployment.setManagedConnectionFactoryAttribute() does not find the method and simply logs it at a trace level, so the value never gets set.






-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 11:04:51 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 2 Jul 2009 11:04:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7072) Don't write a URL
 for host 0.0.0.0 in jnp-service.url
Message-ID: <15437469.1246547091499.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Don't write a URL for host 0.0.0.0 in jnp-service.url
-----------------------------------------------------

                 Key: JBAS-7072
                 URL: https://jira.jboss.org/jira/browse/JBAS-7072
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Management services, Naming
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: JBossAS-5.2.0.Beta1


See JOPR-254 for an explanation of the issue. This issue is to ensure NamingServiceURLWriter writes the correct URL.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 11:12:51 2009
From: jira-events at lists.jboss.org (Mike Conner (JIRA))
Date: Thu, 2 Jul 2009 11:12:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7071) use-try-lock
 option in data source configuration files is ignored
In-Reply-To: <329869123.1246546191859.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1977140896.1246547571410.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474647#action_12474647 ] 

Mike Conner commented on JBAS-7071:
-----------------------------------

One other thing,  the documentation in the dtd (docs\dtd\jboss-ds_5_0.dtd) states:

<!-- Any configured timeout for internal locks on the resource adapter objects in milli-seconds

     The default is a 60 second timeout
     e.g. 5 minutes
     <use-try-lock>300000</use-try-lock>
-->

However, the code in BaseWrapperManagedConnection is actually is doing:

      try
      {
         if (lock.tryLock(tryLock, TimeUnit.SECONDS) == false)
            throw new SQLException("Unable to obtain lock in " + tryLock + " seconds: " + this);
      }

That is, the value represents seconds, not milliseconds.






> use-try-lock option in data source configuration files is ignored
> -----------------------------------------------------------------
>
>                 Key: JBAS-7071
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7071
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows XP Professional V2002, service pack 3
>            Reporter: Mike Conner
>            Assignee: Jesper Pedersen
>            Priority: Minor
>
> (FYI  your "READ THIS BEFORE ENTERING NEW REPORTS" points to a  "You caught us doing a little maintenance..." page, so pardon me if I missed something in procedure. )
> The data source configuration property "use-try-lock" is effectively ignored.
> This is because the value is defined in configuration as a long, but the object that is actually set on  an
> org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory  extends 
>    org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnectionFactory
> This class defines it as taking an int, not a long:
>    public void setUseTryLock(int useTryLock)
> As such, reflection in ManagedConnectionFactoryDeployment.setManagedConnectionFactoryAttribute() does not find the method and simply logs it at a trace level, so the value never gets set.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 11:32:51 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 2 Jul 2009 11:32:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-86) Make concurrent
 calls to getRefClasses() safe.
Message-ID: <119743334.1246548771405.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Make concurrent calls to getRefClasses() safe.
----------------------------------------------

                 Key: JASSIST-86
                 URL: https://jira.jboss.org/jira/browse/JASSIST-86
             Project: Javassist
          Issue Type: Bug
    Affects Versions: 3.10.0.GA
            Reporter: Shigeru Chiba
            Assignee: Shigeru Chiba


There is a race condition when getRefClasses is called twice concurrently on
the same class - one of the chains in HashMap for collision resolution can become
cyclic, i.e. an infinitely long list, causing iteration on the list to enter an
infinite loop.

On a CtClass ct, the call path leading to the problem is:

ct.getRefClasses() -> ct.renameClass() (it's a fake renameClass(), which does
not rename anything) -> ct.constPool.renameClass()

One can thus have concurrent calls to ct.constPool.renameClass(); a constPool
then recreates the internal HashMap, i.e. reinserts again all elements into
cp.classes (not a temporary map), so we have concurrent accesses to this map.
In particular, since there can be a collision (as happened for me), the
collision chain could become cyclic.

This was found through remote debugging on a concurrent program using Javassist
(attaching after a series of run-client invocations ended in a crash). It was a
real-world program, not a client written on purpose to show this.
This patch solves the problem well, and was tested in a configuration which caused a
lot of crashes and stopped causing any.

Lots of better fixes to this could be thought, but they're more invasive.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 11:34:51 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 2 Jul 2009 11:34:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JASSIST-86) Make concurrent
 calls to getRefClasses() safe.
In-Reply-To: <119743334.1246548771405.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <38852961.1246548891729.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba updated JASSIST-86:
---------------------------------

    Attachment: fix-javassist-concurrency


patch file

> Make concurrent calls to getRefClasses() safe.
> ----------------------------------------------
>
>                 Key: JASSIST-86
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-86
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>            Reporter: Shigeru Chiba
>            Assignee: Shigeru Chiba
>         Attachments: fix-javassist-concurrency
>
>
> There is a race condition when getRefClasses is called twice concurrently on
> the same class - one of the chains in HashMap for collision resolution can become
> cyclic, i.e. an infinitely long list, causing iteration on the list to enter an
> infinite loop.
> On a CtClass ct, the call path leading to the problem is:
> ct.getRefClasses() -> ct.renameClass() (it's a fake renameClass(), which does
> not rename anything) -> ct.constPool.renameClass()
> One can thus have concurrent calls to ct.constPool.renameClass(); a constPool
> then recreates the internal HashMap, i.e. reinserts again all elements into
> cp.classes (not a temporary map), so we have concurrent accesses to this map.
> In particular, since there can be a collision (as happened for me), the
> collision chain could become cyclic.
> This was found through remote debugging on a concurrent program using Javassist
> (attaching after a series of run-client invocations ended in a crash). It was a
> real-world program, not a client written on purpose to show this.
> This patch solves the problem well, and was tested in a configuration which caused a
> lot of crashes and stopped causing any.
> Lots of better fixes to this could be thought, but they're more invasive.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 11:43:51 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 2 Jul 2009 11:43:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-87) ClassFile.prune()
 makes a constant pool empty.
Message-ID: <150232651.1246549431739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

ClassFile.prune() makes a constant pool empty.
----------------------------------------------

                 Key: JASSIST-87
                 URL: https://jira.jboss.org/jira/browse/JASSIST-87
             Project: Javassist
          Issue Type: Bug
    Affects Versions: 3.10.0.GA
            Reporter: Shigeru Chiba
            Assignee: Shigeru Chiba
         Attachments: fix-javassist-prune

ClassFile.prune calls ConstPool.prune(), which empties the Constant Pool completely.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 11:43:51 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 2 Jul 2009 11:43:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JASSIST-87) ClassFile.prune()
 makes a constant pool empty.
In-Reply-To: <150232651.1246549431739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1980822433.1246549431806.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba updated JASSIST-87:
---------------------------------

    Attachment: fix-javassist-prune


> ClassFile.prune() makes a constant pool empty.
> ----------------------------------------------
>
>                 Key: JASSIST-87
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-87
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>            Reporter: Shigeru Chiba
>            Assignee: Shigeru Chiba
>         Attachments: fix-javassist-prune
>
>
> ClassFile.prune calls ConstPool.prune(), which empties the Constant Pool completely.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 11:45:51 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 2 Jul 2009 11:45:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-86) Make concurrent
 calls to getRefClasses() safe.
In-Reply-To: <119743334.1246548771405.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1269396007.1246549551664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-86.
----------------------------------

    Fix Version/s: 3.11.0.GA
       Resolution: Done


> Make concurrent calls to getRefClasses() safe.
> ----------------------------------------------
>
>                 Key: JASSIST-86
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-86
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>            Reporter: Shigeru Chiba
>            Assignee: Shigeru Chiba
>             Fix For: 3.11.0.GA
>
>         Attachments: fix-javassist-concurrency
>
>
> There is a race condition when getRefClasses is called twice concurrently on
> the same class - one of the chains in HashMap for collision resolution can become
> cyclic, i.e. an infinitely long list, causing iteration on the list to enter an
> infinite loop.
> On a CtClass ct, the call path leading to the problem is:
> ct.getRefClasses() -> ct.renameClass() (it's a fake renameClass(), which does
> not rename anything) -> ct.constPool.renameClass()
> One can thus have concurrent calls to ct.constPool.renameClass(); a constPool
> then recreates the internal HashMap, i.e. reinserts again all elements into
> cp.classes (not a temporary map), so we have concurrent accesses to this map.
> In particular, since there can be a collision (as happened for me), the
> collision chain could become cyclic.
> This was found through remote debugging on a concurrent program using Javassist
> (attaching after a series of run-client invocations ended in a crash). It was a
> real-world program, not a client written on purpose to show this.
> This patch solves the problem well, and was tested in a configuration which caused a
> lot of crashes and stopped causing any.
> Lots of better fixes to this could be thought, but they're more invasive.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 11:51:51 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 2 Jul 2009 11:51:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-87) ClassFile.prune()
 makes a constant pool empty.
In-Reply-To: <150232651.1246549431739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <383067963.1246549911502.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-87.
----------------------------------

    Fix Version/s: 3.11.0.GA
       Resolution: Done


> ClassFile.prune() makes a constant pool empty.
> ----------------------------------------------
>
>                 Key: JASSIST-87
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-87
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>            Reporter: Shigeru Chiba
>            Assignee: Shigeru Chiba
>             Fix For: 3.11.0.GA
>
>         Attachments: fix-javassist-prune
>
>
> ClassFile.prune calls ConstPool.prune(), which empties the Constant Pool completely.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 12:12:04 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Thu, 2 Jul 2009 12:12:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBAS-7073) ValueExpression is not
 working with JBOSS 5.1.0
Message-ID: <1554358156.1246551124037.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert moved JSFUNIT-216 to JBAS-7073:
--------------------------------------------

        Project: JBoss Application Server  (was: JSFUnit)
            Key: JBAS-7073  (was: JSFUNIT-216)
    Component/s: JSF
                     (was: Core)
       Security: Public


> ValueExpression is not working with JBOSS 5.1.0
> -----------------------------------------------
>
>                 Key: JBAS-7073
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7073
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>         Environment: windows environment
>            Reporter: anil kumar
>            Assignee: Stan Silvert
>            Priority: Critical
>
> sample code is here, its giving  /welcomeJSF.jsp(26,12) According to TLD or attribute directive in tag file, attribute title does not accept any expressions
> welcomeJSF.jsp
> <%@page contentType="text/html"%>
> <%@page pageEncoding="UTF-8"%>
>  <%@ page import="javax.el.ValueExpression"  %>
>  <%@ page import="javax.el.ExpressionFactory"  %>
>   <%@ page import ="com.sun.el.ExpressionFactoryImpl"%>
>  
> <%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
> <%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
>    "http://www.w3.org/TR/html4/loose.dtd">
> <%--
>     This file is an entry point for JavaServer Faces application.
> --%>
> <f:view>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
>         <title>JSP Page</title>
>     </head>
>     <body>
>         
>         <%
>           ExpressionFactory el = new ExpressionFactoryImpl();         
>        ValueExpression testExpression =  el.createValueExpression( " Test" ,  new String().getClass()); 
>         %>
>        
>         <h:form>        
>             <h:commandLink title="<%=testExpression%>" id="next" action="#">
>    <h:outputText value="Next Page ?" />
>     </h:commandLink>
>             <h1><h:outputText value="JavaServer Faces" /></h1>
>        
>     </h:form>
>     </body>
> </html>
>  </f:view>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Thu Jul  2 12:32:51 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Thu, 2 Jul 2009 12:32:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7073) ValueExpression is
 not working with JBOSS 5.1.0
Message-ID: <1711371571.1246552371644.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474661#action_12474661 ] 

Stan Silvert commented on JBAS-7073:
------------------------------------

It's not talking about the ValueExpression.  It's talking about the fact that you used <%=something%>.  This is not allowed for the title attribute.  

> ValueExpression is not working with JBOSS 5.1.0
> -----------------------------------------------
>
>                 Key: JBAS-7073
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7073
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>         Environment: windows environment
>            Reporter: anil kumar
>            Assignee: Stan Silvert
>            Priority: Critical
>
> sample code is here, its giving  /welcomeJSF.jsp(26,12) According to TLD or attribute directive in tag file, attribute title does not accept any expressions
> welcomeJSF.jsp
> <%@page contentType="text/html"%>
> <%@page pageEncoding="UTF-8"%>
>  <%@ page import="javax.el.ValueExpression"  %>
>  <%@ page import="javax.el.ExpressionFactory"  %>
>   <%@ page import ="com.sun.el.ExpressionFactoryImpl"%>
>  
> <%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
> <%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
>    "http://www.w3.org/TR/html4/loose.dtd">
> <%--
>     This file is an entry point for JavaServer Faces application.
> --%>
> <f:view>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
>         <title>JSP Page</title>
>     </head>
>     <body>
>         
>         <%
>           ExpressionFactory el = new ExpressionFactoryImpl();         
>        ValueExpression testExpression =  el.createValueExpression( " Test" ,  new String().getClass()); 
>         %>
>        
>         <h:form>        
>             <h:commandLink title="<%=testExpression%>" id="next" action="#">
>    <h:outputText value="Next Page ?" />
>     </h:commandLink>
>             <h1><h:outputText value="JavaServer Faces" /></h1>
>        
>     </h:form>
>     </body>
> </html>
>  </f:view>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Thu Jul  2 12:32:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 2 Jul 2009 12:32:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBASPECT-32) Fix dependency
	upon JACC API
Message-ID: <228336563.1246552371423.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Fix dependency upon JACC API
----------------------------

                 Key: JBASPECT-32
                 URL: https://jira.jboss.org/jira/browse/JBASPECT-32
             Project: JBoss Aspects
          Issue Type: Task
          Components: security
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 1.0.1.GA-security 


>From AS Branch_5_x "build" module:
[INFO] [dependency:tree]
[INFO] org.jboss.jbossas:jboss-as-build:pom:5.2.0-SNAPSHOT
[INFO] \- org.jboss.jbossas:jboss-as-aspects:jar:5.2.0-SNAPSHOT:compile
[INFO]    \- org.jboss.aspects:jboss-security-aspects:jar:1.0.0.GA:compile
[INFO]       \- javax.security:jacc:jar:1.0:compil

Instead we need to be defining the dependency upon "org.jboss.javaee:jboss-javaee".

As a result this doesn't make it into the AS dependency tree correctly (though the build places the proper artifact into the distribution/runtime).  Embedded gets the wrong artifact as a result.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 12:34:51 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Thu, 2 Jul 2009 12:34:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7073) ValueExpression is
 not working with JBOSS 5.1.0
Message-ID: <201867251.1246552491436.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert resolved JBAS-7073.
--------------------------------

    Resolution: Rejected


> ValueExpression is not working with JBOSS 5.1.0
> -----------------------------------------------
>
>                 Key: JBAS-7073
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7073
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>         Environment: windows environment
>            Reporter: anil kumar
>            Assignee: Stan Silvert
>            Priority: Critical
>
> sample code is here, its giving  /welcomeJSF.jsp(26,12) According to TLD or attribute directive in tag file, attribute title does not accept any expressions
> welcomeJSF.jsp
> <%@page contentType="text/html"%>
> <%@page pageEncoding="UTF-8"%>
>  <%@ page import="javax.el.ValueExpression"  %>
>  <%@ page import="javax.el.ExpressionFactory"  %>
>   <%@ page import ="com.sun.el.ExpressionFactoryImpl"%>
>  
> <%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
> <%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
>    "http://www.w3.org/TR/html4/loose.dtd">
> <%--
>     This file is an entry point for JavaServer Faces application.
> --%>
> <f:view>
> <html>
>     <head>
>         <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
>         <title>JSP Page</title>
>     </head>
>     <body>
>         
>         <%
>           ExpressionFactory el = new ExpressionFactoryImpl();         
>        ValueExpression testExpression =  el.createValueExpression( " Test" ,  new String().getClass()); 
>         %>
>        
>         <h:form>        
>             <h:commandLink title="<%=testExpression%>" id="next" action="#">
>    <h:outputText value="Next Page ?" />
>     </h:commandLink>
>             <h1><h:outputText value="JavaServer Faces" /></h1>
>        
>     </h:form>
>     </body>
> </html>
>  </f:view>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Thu Jul  2 14:22:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 2 Jul 2009 14:22:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBASPECT-32) Fix dependency
	upon JACC API
In-Reply-To: <228336563.1246552371423.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <862886610.1246558971583.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBASPECT-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBASPECT-32.
-----------------------------------------

    Resolution: Done


> Fix dependency upon JACC API
> ----------------------------
>
>                 Key: JBASPECT-32
>                 URL: https://jira.jboss.org/jira/browse/JBASPECT-32
>             Project: JBoss Aspects
>          Issue Type: Task
>          Components: security
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.0.1-security 
>
>
> From AS Branch_5_x "build" module:
> [INFO] [dependency:tree]
> [INFO] org.jboss.jbossas:jboss-as-build:pom:5.2.0-SNAPSHOT
> [INFO] \- org.jboss.jbossas:jboss-as-aspects:jar:5.2.0-SNAPSHOT:compile
> [INFO]    \- org.jboss.aspects:jboss-security-aspects:jar:1.0.0.GA:compile
> [INFO]       \- javax.security:jacc:jar:1.0:compil
> Instead we need to be defining the dependency upon "org.jboss.javaee:jboss-javaee".
> As a result this doesn't make it into the AS dependency tree correctly (though the build places the proper artifact into the distribution/runtime).  Embedded gets the wrong artifact as a result.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 14:24:51 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Thu, 2 Jul 2009 14:24:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1862) False WARN
 message if res-type is missing in resource-ref
Message-ID: <455794687.1246559091538.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

False WARN message if res-type is missing in resource-ref
---------------------------------------------------------

                 Key: EJBTHREE-1862
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1862
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: 1.1.7
            Reporter: Wolfgang Knauf
            Priority: Minor


This one was introduced by https://jira.jboss.org/jira/browse/EJBTHREE-1823

I think this warn message is a slight violation of the spec (chapter 16.7.1.3 of EJB3 spec and 5.6.2 of JavaEE5 spec):

"The resource-ref element consists of ... the optional res-type .... The res-type element is optional if an injection target is specified for the
resource; in this case, the res-type defaults to the type of the injection target." 

So, the warning should only be output if no injection target is specified.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 14:36:51 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Thu, 2 Jul 2009 14:36:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1863) res-type in
 resource-ref is not checked
Message-ID: <2026359205.1246559811397.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

res-type in resource-ref is not checked
---------------------------------------

                 Key: EJBTHREE-1863
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1863
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: 1.1.7
            Reporter: Wolfgang Knauf


The "res-type" of the "resource-ref" element in ejb-jar.xml is not verified.

See the attached sample: neither on deploy nor on JNDI lookup, an error is raised for this xml snippet, which contains an invalid res-type:
			<resource-ref>
				<res-ref-name>EnvNameOfSessionContext1</res-ref-name>
 				<res-type>whole.lotta.Crap</res-type>
				<mapped-name>java:comp/EJBContext</mapped-name>
				<injection-target>
					<injection-target-class>de.knauf.resourceref.ResourceRefTestBean</injection-target-class>
					<injection-target-name>sessionContext1</injection-target-name>
			  	</injection-target>
			</resource-ref>

			<resource-ref>
				<res-ref-name>EnvNameOfSessionContext2</res-ref-name>
 				<res-type>whole.lotta.Crap</res-type>
				<mapped-name>java:comp/EJBContext</mapped-name>
			</resource-ref>
The class org.jboss.injection.ResourceHandler.loadXmlResourceRefs almost completely ignores the "res-type" element ;-).

For a "resource-env-ref" element, the "resource-env-ref-type" is validated, though maybe this happens by accident ;-):
Caused by: java.lang.ClassNotFoundException: asdjavax.ejb.SessionContext from BaseClassLoader at 22adfd{...}
	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:448)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClassInternal(Unknown Source)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Unknown Source)
	at org.jboss.injection.ResourceHandler.loadXmlResourceEnvRefs(ResourceHandler.java:217)
	... 73 more

So, I would like a similar check for the "resource-ref" res-type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 14:38:51 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Thu, 2 Jul 2009 14:38:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1863) res-type in
 resource-ref is not checked
In-Reply-To: <2026359205.1246559811397.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <788044456.1246559931931.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolfgang Knauf updated EJBTHREE-1863:
-------------------------------------

    Attachment: ResourceRef.ear


Sample containing an ejb-jar.xml with two invalid "res-type" values. One "resource-ref" is used for injection, the other just provides an ENC entry. In both cases, no error is raised.

To test it: deploy ear and browse to http://localhost:8080/ResourceRefWeb/ 
Then take a look at the console to see some status output.
The session bean "ResourceRefTestBean" contains a business method which accesses the injected SessionContext and looks up another ENC SessionContext

> res-type in resource-ref is not checked
> ---------------------------------------
>
>                 Key: EJBTHREE-1863
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1863
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.7
>            Reporter: Wolfgang Knauf
>         Attachments: ResourceRef.ear
>
>
> The "res-type" of the "resource-ref" element in ejb-jar.xml is not verified.
> See the attached sample: neither on deploy nor on JNDI lookup, an error is raised for this xml snippet, which contains an invalid res-type:
> 			<resource-ref>
> 				<res-ref-name>EnvNameOfSessionContext1</res-ref-name>
>  				<res-type>whole.lotta.Crap</res-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 				<injection-target>
> 					<injection-target-class>de.knauf.resourceref.ResourceRefTestBean</injection-target-class>
> 					<injection-target-name>sessionContext1</injection-target-name>
> 			  	</injection-target>
> 			</resource-ref>
> 			<resource-ref>
> 				<res-ref-name>EnvNameOfSessionContext2</res-ref-name>
>  				<res-type>whole.lotta.Crap</res-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 			</resource-ref>
> The class org.jboss.injection.ResourceHandler.loadXmlResourceRefs almost completely ignores the "res-type" element ;-).
> For a "resource-env-ref" element, the "resource-env-ref-type" is validated, though maybe this happens by accident ;-):
> Caused by: java.lang.ClassNotFoundException: asdjavax.ejb.SessionContext from BaseClassLoader at 22adfd{...}
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:448)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClassInternal(Unknown Source)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Unknown Source)
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceEnvRefs(ResourceHandler.java:217)
> 	... 73 more
> So, I would like a similar check for the "resource-ref" res-type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 15:09:52 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 2 Jul 2009 15:09:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2155) Make parsing of
 bendpoints more error-safe
Message-ID: <265628206.1246561792199.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Make parsing of bendpoints more error-safe
------------------------------------------

                 Key: JBRULES-2155
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2155
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler (flow)
            Reporter: Kris Verlaenen
            Assignee: Kris Verlaenen
             Fix For: 5.1.0.M1


In cases where the bendpoints are not specified as expected in the XML, the parser would throw out exceptions that don't contain a lot of information about the cause.
E.g.
java.lang.NumberFormatException: For input string: ""
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:468)
at java.lang.Integer.<init>(Integer.java:620)
at org.drools.eclipse.flow.ruleflow.core.ConnectionWrapper.stringToBendpoints(ConnectionWrapper.java:94)
at org.drools.eclipse.flow.ruleflow.core.ConnectionWrapper.internalGetBendpoints(ConnectionWrapper.java:65)
at org.drools.eclipse.flow.common.editor.core.ElementConnection.getBendpoints(ElementConnection.java:123)
...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 15:17:51 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 2 Jul 2009 15:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2155) Make parsing of
 bendpoints more error-safe
In-Reply-To: <265628206.1246561792199.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1487975114.1246562271893.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen resolved JBRULES-2155.
-------------------------------------

    Resolution: Done


Done

> Make parsing of bendpoints more error-safe
> ------------------------------------------
>
>                 Key: JBRULES-2155
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2155
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (flow)
>            Reporter: Kris Verlaenen
>            Assignee: Kris Verlaenen
>             Fix For: 5.1.0.M1
>
>
> In cases where the bendpoints are not specified as expected in the XML, the parser would throw out exceptions that don't contain a lot of information about the cause.
> E.g.
> java.lang.NumberFormatException: For input string: ""
> at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
> at java.lang.Integer.parseInt(Integer.java:468)
> at java.lang.Integer.<init>(Integer.java:620)
> at org.drools.eclipse.flow.ruleflow.core.ConnectionWrapper.stringToBendpoints(ConnectionWrapper.java:94)
> at org.drools.eclipse.flow.ruleflow.core.ConnectionWrapper.internalGetBendpoints(ConnectionWrapper.java:65)
> at org.drools.eclipse.flow.common.editor.core.ElementConnection.getBendpoints(ElementConnection.java:123)
> ...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 15:20:51 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Thu, 2 Jul 2009 15:20:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7074) some jars required
 by remote Profile Service clients are not included in client/ or
 client/jboss-clientall.jar
Message-ID: <631441563.1246562451433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

some jars required by remote Profile Service clients are not included in client/ or client/jboss-clientall.jar
--------------------------------------------------------------------------------------------------------------

                 Key: JBAS-7074
                 URL: https://jira.jboss.org/jira/browse/JBAS-7074
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Ian Springer
            Assignee: Scott M Stark
             Fix For: JBossAS-5.2.0.Beta1


The classes from the following jar are missing from jboss-clientall.jar and the jar itself is missing from client/:

   common/lib/jboss-security-aspects.jar

Its corresponding Maven artifact is org.jboss.aspects:jboss-security-aspects.

If I find any others, I will update this JIRA.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 15:28:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 2 Jul 2009 15:28:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-100) SJC/RADeployer:
	Classloading
In-Reply-To: <855624937.1246457871714.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <52672742.1246562931405.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-100.
-----------------------------------

    Resolution: Done


> SJC/RADeployer: Classloading
> ----------------------------
>
>                 Key: JBJCA-100
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-100
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Add a classloader to each deployment unit in the SJC resource adapter deployer.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 14:58:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 2 Jul 2009 14:58:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-103) Javassist 3.11 GA
Message-ID: <1839914087.1246561131576.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Javassist 3.11 GA
-----------------

                 Key: JBJCA-103
                 URL: https://jira.jboss.org/jira/browse/JBJCA-103
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 15:44:51 2009
From: jira-events at lists.jboss.org (Gurkan Erdogdu (JIRA))
Date: Thu, 2 Jul 2009 15:44:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-104) Developer
 Documentation Patch for Module building.xml
Message-ID: <255543035.1246563891511.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Developer Documentation Patch for Module building.xml
-----------------------------------------------------

                 Key: JBJCA-104
                 URL: https://jira.jboss.org/jira/browse/JBJCA-104
             Project: JBoss JCA
          Issue Type: Patch
          Components: Documentation
            Reporter: Gurkan Erdogdu
            Assignee: Jesper Pedersen


Patch for developer guides building.xml. Adding some documentation about building.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 15:46:51 2009
From: jira-events at lists.jboss.org (Gurkan Erdogdu (JIRA))
Date: Thu, 2 Jul 2009 15:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-104) Developer
 Documentation Patch for Module building.xml
In-Reply-To: <255543035.1246563891511.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1331059353.1246564011784.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gurkan Erdogdu updated JBJCA-104:
---------------------------------

    Attachment: building.patch


> Developer Documentation Patch for Module building.xml
> -----------------------------------------------------
>
>                 Key: JBJCA-104
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-104
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Documentation
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>         Attachments: building.patch
>
>
> Patch for developer guides building.xml. Adding some documentation about building.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 16:12:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 2 Jul 2009 16:12:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-104) Developer
 Documentation Patch for Module building.xml
In-Reply-To: <255543035.1246563891511.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <197274060.1246565571438.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-104.
-----------------------------------

    Resolution: Done


> Developer Documentation Patch for Module building.xml
> -----------------------------------------------------
>
>                 Key: JBJCA-104
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-104
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Documentation
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>         Attachments: building.patch
>
>
> Patch for developer guides building.xml. Adding some documentation about building.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 16:38:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 2 Jul 2009 16:38:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-104) Developer
 Documentation Patch for Module building.xml
In-Reply-To: <255543035.1246563891511.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <526883160.1246567131691.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-104.
-----------------------------------

    Fix Version/s: 1.0.0.Alpha2
       Resolution: Done


> Developer Documentation Patch for Module building.xml
> -----------------------------------------------------
>
>                 Key: JBJCA-104
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-104
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Documentation
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>         Attachments: building.patch
>
>
> Patch for developer guides building.xml. Adding some documentation about building.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 16:38:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 2 Jul 2009 16:38:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBJCA-104) Developer
 Documentation Patch for Module building.xml
In-Reply-To: <255543035.1246563891511.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1552971049.1246567131512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen reopened JBJCA-104:
-----------------------------------



> Developer Documentation Patch for Module building.xml
> -----------------------------------------------------
>
>                 Key: JBJCA-104
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-104
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Documentation
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>         Attachments: building.patch
>
>
> Patch for developer guides building.xml. Adding some documentation about building.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 18:41:51 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 2 Jul 2009 18:41:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1504) Full Journal
	Compactation
In-Reply-To: <33137475.1234453664451.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1338473396.1246574511475.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1504.
----------------------------------------

    Resolution: Done


> Full Journal Compactation
> -------------------------
>
>                 Key: JBMESSAGING-1504
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1504
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> Let me describe how I think the compacting should work.
> Let's say we have a set of files in the journal:
> F0, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10
> min files is set to 10
> The current file is F6 and F7, F8, F9, F10 are unused files waiting to be used
> F0, F1, F2, F3, F4, F5 are files full of data and not open any more, however, data about their contents are stored in memory.
> We need a compacting thread that intermittently (say every 30 seconds) scans the set of journal files in memory.
> It scans F0... F5, and when it has completed that scan, it can decide which records are no longer needed in each file.
> A record is no longer needed in a file if it has already been deleted in any file F0.. F5.
> Once the scanner thread has computed which records are needed and which are not, it can compute a percentage of which records in total are dead space.
> E.g. the scanner might compute that 72% of the data in files F0.. .F5 are dead space.
> We then have a parameter that the user can configure compactorDeadSpaceThresholdPercentage, e.g. this might have a default of 75%.
> If the amount of dead space computed by the scanner >= compactorDeadSpaceThresholdPercentage, then the scanner will compact those files.
> The actual compacting approach goes as follows:
> The scanner knows how many new files it will need for the compacted records, let's say it needs two new files - it can get these from the unused files (e.g. F7, F8, F9 or F10) if they are available.
> It then opens the old files F0..F5 loads the wanted records into memory in blocks and copies them to the new files.
> When this process is finished it will end up with, say, two new files containing the compacted records.
> We can then save a marker file (empty in the journal directory) which says we are starting the rename.
> The old files F0..F5 then need to be renamed so they are no longer used by the journal (but can be recovered in case of a crash).
> Then the two new files need to be renamed so they will be picked up by the journal.
> When that process completes the marker file can be deleted.
> If the server crashes after renaming the old files but before renaming the new files, then the marker file will still exist in the journal. The journal can detect this on startup, and finish the process.
> This ensures the journal will still startup after such a crash.
> Also the JournalFile objects also need to be updated in memory when the compact is complete.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 20:32:51 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 2 Jul 2009 20:32:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2156) Improved BPMN2
	skin
Message-ID: <1369383098.1246581171419.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Improved BPMN2 skin
-------------------

                 Key: JBRULES-2156
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2156
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-eclipse (flow)
            Reporter: Kris Verlaenen
            Assignee: Kris Verlaenen
             Fix For: 5.1.0.M1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 23:25:51 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 2 Jul 2009 23:25:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JASSIST-86) Make concurrent
 calls to getRefClasses() safe.
In-Reply-To: <119743334.1246548771405.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1821628319.1246591551506.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JASSIST-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474773#action_12474773 ] 

Shigeru Chiba commented on JASSIST-86:
--------------------------------------

This patch was provided by Paolo 'Blaisorblade' Giarrusso.

> Make concurrent calls to getRefClasses() safe.
> ----------------------------------------------
>
>                 Key: JASSIST-86
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-86
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>            Reporter: Shigeru Chiba
>            Assignee: Shigeru Chiba
>             Fix For: 3.11.0.GA
>
>         Attachments: fix-javassist-concurrency
>
>
> There is a race condition when getRefClasses is called twice concurrently on
> the same class - one of the chains in HashMap for collision resolution can become
> cyclic, i.e. an infinitely long list, causing iteration on the list to enter an
> infinite loop.
> On a CtClass ct, the call path leading to the problem is:
> ct.getRefClasses() -> ct.renameClass() (it's a fake renameClass(), which does
> not rename anything) -> ct.constPool.renameClass()
> One can thus have concurrent calls to ct.constPool.renameClass(); a constPool
> then recreates the internal HashMap, i.e. reinserts again all elements into
> cp.classes (not a temporary map), so we have concurrent accesses to this map.
> In particular, since there can be a collision (as happened for me), the
> collision chain could become cyclic.
> This was found through remote debugging on a concurrent program using Javassist
> (attaching after a series of run-client invocations ended in a crash). It was a
> real-world program, not a client written on purpose to show this.
> This patch solves the problem well, and was tested in a configuration which caused a
> lot of crashes and stopped causing any.
> Lots of better fixes to this could be thought, but they're more invasive.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  2 23:27:51 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 2 Jul 2009 23:27:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JASSIST-87) ClassFile.prune()
 makes a constant pool empty.
In-Reply-To: <150232651.1246549431739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <891259711.1246591671777.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JASSIST-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474775#action_12474775 ] 

Shigeru Chiba commented on JASSIST-87:
--------------------------------------

This bug was reported by Paolo 'Blaisorblade' Giarrusso, who also provided the fix.

> ClassFile.prune() makes a constant pool empty.
> ----------------------------------------------
>
>                 Key: JASSIST-87
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-87
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.10.0.GA
>            Reporter: Shigeru Chiba
>            Assignee: Shigeru Chiba
>             Fix For: 3.11.0.GA
>
>         Attachments: fix-javassist-prune
>
>
> ClassFile.prune calls ConstPool.prune(), which empties the Constant Pool completely.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 00:27:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 3 Jul 2009 00:27:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-94)
 JBossASConfigurationInitializer has wrong default bind address
Message-ID: <477561768.1246595271936.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBossASConfigurationInitializer has wrong default bind address
--------------------------------------------------------------

                 Key: JBBOOT-94
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-94
             Project: JBoss Bootstrap
          Issue Type: Bug
          Components: spi-as
    Affects Versions: 2.0.0-alpha-1
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 2.0.0-beta-1 


String VALUE_BIND_ADDRESS_DEFAULT = "127.0.0.0"; 

...should be "127.0.0.1".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 00:29:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 3 Jul 2009 00:29:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-94)
 JBossASConfigurationInitializer has wrong default bind address
In-Reply-To: <477561768.1246595271936.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1974688679.1246595391880.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated JBBOOT-94:
--------------------------------------

    Fix Version/s: spi-as-2.0.0-alpha-2 
                       (was: 2.0.0-beta-1 )


> JBossASConfigurationInitializer has wrong default bind address
> --------------------------------------------------------------
>
>                 Key: JBBOOT-94
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-94
>             Project: JBoss Bootstrap
>          Issue Type: Bug
>          Components: spi-as
>    Affects Versions: 2.0.0-alpha-1
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: spi-as-2.0.0-alpha-2 
>
>
> String VALUE_BIND_ADDRESS_DEFAULT = "127.0.0.0"; 
> ...should be "127.0.0.1".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 01:42:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 3 Jul 2009 01:42:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-94)
 JBossASConfigurationInitializer has wrong default bind address
In-Reply-To: <477561768.1246595271936.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1090570345.1246599771458.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-94.
---------------------------------------

    Resolution: Done


> JBossASConfigurationInitializer has wrong default bind address
> --------------------------------------------------------------
>
>                 Key: JBBOOT-94
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-94
>             Project: JBoss Bootstrap
>          Issue Type: Bug
>          Components: spi-as
>    Affects Versions: 2.0.0-alpha-1
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: spi-as-2.0.0-alpha-2 
>
>
> String VALUE_BIND_ADDRESS_DEFAULT = "127.0.0.0"; 
> ...should be "127.0.0.1".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 03:12:51 2009
From: jira-events at lists.jboss.org (Vladimir Blagojevic (JIRA))
Date: Fri, 3 Jul 2009 03:12:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1006) Shared transport:
 shunned multiple channels can not reconnect
In-Reply-To: <1360522755.1246439551381.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <503893208.1246605171588.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Blagojevic updated JGRP-1006:
--------------------------------------

    Fix Version/s: 2.8


> Shared transport: shunned multiple channels can not reconnect 
> --------------------------------------------------------------
>
>                 Key: JGRP-1006
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1006
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6
>            Reporter: Vladimir Blagojevic
>            Assignee: Vladimir Blagojevic
>             Fix For: 2.6.11, 2.8
>
>
> Brian Stansberry said:
> One of the EJB3/AS integration testsuite runs hit a JGroups problem last 
> night. *Looks like* some issue between the two AS nodes (127.0.0.1 and 
> 127.0.0.2) in the test caused the channels in one node to be 
> suspected/reconnect. Which didn't go well -- which is the subject of 
> this thread.
> I have the server logs from both, which record at INFO or above; if 
> anyone wants them, ping me. Here are the highlights:
> 1) Both nodes connect 4 channels as part of AS startup: 3 using a shared 
> transport UDP stack (for JBC, HAPartition, JBM) and one TCP one for JBM.
> 2) A bunch of test cases then execute, each deploys an EJB3 jar on each 
> node in turn, which in turn causes another JBC channel to be created and 
> connect at test start and disconnect and close at test end. This channel 
> uses the same shared  transport as the other 3, so now there are four 
> channels using that shared transport.
> 3) This create/close cycle continues a while, until on one node there is 
> some issue that results in one of the 4 UDP channels suspecting its peer 
> and all 4 UDP channels getting a new view:
> 13:23:58,150 INFO  [DefaultPartition] Suspected member: 127.0.0.1:40089
> 13:23:58,257 INFO  [GroupMember] 
> org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 4cfcb4de 
> got new view [127.0.0.2:42088|2] [127.0.0.2:42088], old view is 
> [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088]
> 13:23:58,257 INFO  [GroupMember] I am (127.0.0.2:42088)
> 13:23:58,265 INFO  [DefaultPartition] New cluster view for partition 
> DefaultPartition (id: 2, delta: -1) : [127.0.0.2:1099]
> 13:23:58,275 INFO  [MessagingPostOffice] JBoss Messaging is failing over 
> for failed node 0. If there are many messages to reload this may take 
> some time...
> 13:23:58,442 INFO  [DefaultPartition] I am (127.0.0.2:1099) received 
> membershipChanged event:
> 13:23:58,442 INFO  [DefaultPartition] Dead members: 1 ([127.0.0.1:1099])
> 13:23:58,442 INFO  [DefaultPartition] New Members : 0 ([])
> 13:23:58,442 INFO  [DefaultPartition] All Members : 1 ([127.0.0.2:1099])
> 13:23:58,581 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|2] [127.0.0.2:42088]
> 13:23:58,620 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|2] [127.0.0.2:42088]
> 13:24:00,260 WARN  [GMS] 127.0.0.2:42088 failed to collect all ACKs (1) 
> for mcasted view [127.0.0.2:42088|2] [127.0.0.2:42088] after 2000ms, 
> missing ACKs from [127.0.0.2:42088] (received=[]), 
> local_addr=127.0.0.2:42088
> 13:24:00,661 INFO  [MessagingPostOffice] JBoss Messaging failover completed
> 13:24:00,662 INFO  [GroupMember] Dead members: 1 ([127.0.0.1:40089])
> 13:24:00,662 INFO  [GroupMember] All Members : 1 ([127.0.0.2:42088])
> 4) At some point the suspected node realizes it is suspected and the 4 
> UDP channels decide to reconnect, two at about the same time and the 
> other two w/in 55 ms of the first two:
> 13:24:39,294 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,295 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,315 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,325 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,339 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 13:24:39,359 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,360 WARN  [FD] I was suspected by 127.0.0.2:42088; ignoring the 
> SUSPECT message and sending back a HEARTBEAT_ACK
> 13:24:39,380 WARN  [GMS] I (127.0.0.1:40089) am not a member of view 
> [127.0.0.2:42088|2] [127.0.0.2:42088], shunning myself and leaving the 
> group (prev_members are [127.0.0.1:40089, 127.0.0.2:42088], current view 
> is [127.0.0.1:40089|1] [127.0.0.1:40089, 127.0.0.2:42088])
> 5) This is where things break down.  It looks like one of the 4 channels 
> is able to get a local_addr, but the others get null. Perhaps a 
> concurrency bug in Configurator.startProtocolStack? (Note the first 2 
> lines below have to do with the independent TCP channel used by JBM; I 
> post them for completeness.)
> 13:24:39,568 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:39,959 ERROR [ConnectionTable] failed sending data to 
> 127.0.0.2:7900: java.net.SocketException: Broken pipe
> 13:24:40,833 WARN  [GMS]
> 13:24:40,834 WARN  [GMS]
> 13:24:41,362 INFO  [STDOUT]
> ---------------------------------------------------------
> GMS: address is 127.0.0.1:56000 (cluster=DefaultPartition-SFSBCache)
> ---------------------------------------------------------
> 13:24:41,362 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,488 INFO  [RPCManagerImpl] Received new cluster view: 
> [127.0.0.2:42088|3] [127.0.0.2:42088, 127.0.0.1:56000]
> 13:24:41,564 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,564 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> 13:24:41,927 INFO  [LegacyStateTransferIntegrator] Using version 4096
> 13:24:45,941 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
> 13:24:45,993 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:7900, 127.0.0.1:7900]
> 13:24:45,995 WARN  [GMS] merge was supposed to be cancelled at merge 
> participant 127.0.0.1:7900 (merge_id=[127.0.0.1:7900|1246037080987]), 
> but it is not since merge ids do not match
> 13:24:46,029 WARN  [GMS] Merge aborted. Merge leader did not get 
> MergeData from all subgroup coordinators [127.0.0.2:42088, 127.0.0.1:40089]
> 13:24:46,029 WARN  [GMS] resume([127.0.0.1:40089|1246037080833]) does 
> not match null
> 6) Thereafter, there is continual looping of the CloserThread as it 
> tries to connect a channel, fails due to local_addr == null, waits 1 sec 
> and tries again, which goes on for hours:
> 13:24:41,363 FATAL [JChannel] local_addr is null; cannot connect
> 13:24:41,365 ERROR [JChannel] failure reconnecting to channel, retrying
> org.jgroups.ChannelException: local_addr is null
> 	at org.jgroups.JChannel.startStack(JChannel.java:1631)
> 	at org.jgroups.JChannel.connect(JChannel.java:366)
> 	at org.jgroups.JChannel$CloserThread.run(JChannel.java:2046)
> As I said, I suspect a concurrency issue that's resulting in one channel 
> getting a local_addr but thereafter others with the same shared 
> transport get null.
> Hmm, just noticed: the looping in #6 above repeats every 30 secs, not 
> every second. Which is the timeout in JChannel.startStack() :
> /* Wait LOCAL_ADDR_TIMEOUT milliseconds for local_addr to have a 
> non-null value (set by SET_LOCAL_ADDRESS) */
> local_addr=local_addr_promise.getResult(LOCAL_ADDR_TIMEOUT);
> if(local_addr == null) {
>      log.fatal("local_addr is null; cannot connect");
>      throw new ChannelException("local_addr is null");
> }
> So, seems the recurring problem is local_addr_promise isn't getting set, 
> not that it is getting set, but with a null value. *However* the *first* 
> set of FATAL logging occurs just a couple seconds after GMS logs it is 
> going to reconnect. So that first issue where local_addr == null is not 
> due to a timeout.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 03:14:51 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 3 Jul 2009 03:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1863) res-type in
 resource-ref is not checked
In-Reply-To: <2026359205.1246559811397.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <227271483.1246605291420.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned EJBTHREE-1863:
--------------------------------------

    Assignee: jaikiran pai


> res-type in resource-ref is not checked
> ---------------------------------------
>
>                 Key: EJBTHREE-1863
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1863
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.7
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>         Attachments: ResourceRef.ear
>
>
> The "res-type" of the "resource-ref" element in ejb-jar.xml is not verified.
> See the attached sample: neither on deploy nor on JNDI lookup, an error is raised for this xml snippet, which contains an invalid res-type:
> 			<resource-ref>
> 				<res-ref-name>EnvNameOfSessionContext1</res-ref-name>
>  				<res-type>whole.lotta.Crap</res-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 				<injection-target>
> 					<injection-target-class>de.knauf.resourceref.ResourceRefTestBean</injection-target-class>
> 					<injection-target-name>sessionContext1</injection-target-name>
> 			  	</injection-target>
> 			</resource-ref>
> 			<resource-ref>
> 				<res-ref-name>EnvNameOfSessionContext2</res-ref-name>
>  				<res-type>whole.lotta.Crap</res-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 			</resource-ref>
> The class org.jboss.injection.ResourceHandler.loadXmlResourceRefs almost completely ignores the "res-type" element ;-).
> For a "resource-env-ref" element, the "resource-env-ref-type" is validated, though maybe this happens by accident ;-):
> Caused by: java.lang.ClassNotFoundException: asdjavax.ejb.SessionContext from BaseClassLoader at 22adfd{...}
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:448)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClassInternal(Unknown Source)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Unknown Source)
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceEnvRefs(ResourceHandler.java:217)
> 	... 73 more
> So, I would like a similar check for the "resource-ref" res-type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 03:16:51 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 3 Jul 2009 03:16:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1862) False WARN
 message if res-type is missing in resource-ref
In-Reply-To: <455794687.1246559091538.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <586809558.1246605411471.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned EJBTHREE-1862:
--------------------------------------

    Assignee: jaikiran pai


> False WARN message if res-type is missing in resource-ref
> ---------------------------------------------------------
>
>                 Key: EJBTHREE-1862
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1862
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.7
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>            Priority: Minor
>
> This one was introduced by https://jira.jboss.org/jira/browse/EJBTHREE-1823
> I think this warn message is a slight violation of the spec (chapter 16.7.1.3 of EJB3 spec and 5.6.2 of JavaEE5 spec):
> "The resource-ref element consists of ... the optional res-type .... The res-type element is optional if an injection target is specified for the
> resource; in this case, the res-type defaults to the type of the injection target." 
> So, the warning should only be output if no injection target is specified.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 03:55:51 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 3 Jul 2009 03:55:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBXB-209) Enum parsing
 requires value equal to type name
In-Reply-To: <1699476865.1246607631546.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <922707601.1246607751379.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBXB-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474785#action_12474785 ] 

Thomas Diesler commented on JBXB-209:
-------------------------------------

If I change the type name to 

public enum TAvailability
{
   mandatory("mandatory"), 
   optional("optional");

   ...
}

(which is not a recommended enum type name) - it seems to work

> Enum parsing requires value equal to type name
> ----------------------------------------------
>
>                 Key: JBXB-209
>                 URL: https://jira.jboss.org/jira/browse/JBXB-209
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Thomas Diesler
>
> Caused by: java.lang.RuntimeException: Invalid value mandatory valid are [MANDATORY, OPTIONAL]
> 	at org.jboss.xb.builder.runtime.EnumValueAdapter.cast(EnumValueAdapter.java:136)
> 	at org.jboss.xb.builder.runtime.AbstractPropertyHandler.attribute(AbstractPropertyHandler.java:115)
> 	at org.jboss.xb.binding.sunday.unmarshalling.AttributesHandler.attributes(AttributesHandler.java:51)
> 	at org.jboss.xb.binding.sunday.unmarshalling.DefaultElementHandler.attributes(DefaultElementHandler.java:65)
> 	at org.jboss.xb.builder.runtime.BeanHandler.startParticle(BeanHandler.java:124)
> 	at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:630)
> 	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:401)
> 	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
> public enum TAvailability
> {
>    MANDATORY("mandatory"), 
>    OPTIONAL("optional");
>    private final String value;
>    TAvailability(String v)
>    {
>       value = v;
>    }
>    public String value()
>    {
>       return value;
>    }
>    public static TAvailability fromValue(String v)
>    {
>       for (TAvailability c : TAvailability.values())
>       {
>          if (c.value.equals(v))
>          {
>             return c;
>          }
>       }
>       throw new IllegalArgumentException(v);
>    }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 03:53:51 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 3 Jul 2009 03:53:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-209) Enum parsing requires
 value equal to type name
Message-ID: <1699476865.1246607631546.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Enum parsing requires value equal to type name
----------------------------------------------

                 Key: JBXB-209
                 URL: https://jira.jboss.org/jira/browse/JBXB-209
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.1.GA
            Reporter: Thomas Diesler


Caused by: java.lang.RuntimeException: Invalid value mandatory valid are [MANDATORY, OPTIONAL]
	at org.jboss.xb.builder.runtime.EnumValueAdapter.cast(EnumValueAdapter.java:136)
	at org.jboss.xb.builder.runtime.AbstractPropertyHandler.attribute(AbstractPropertyHandler.java:115)
	at org.jboss.xb.binding.sunday.unmarshalling.AttributesHandler.attributes(AttributesHandler.java:51)
	at org.jboss.xb.binding.sunday.unmarshalling.DefaultElementHandler.attributes(DefaultElementHandler.java:65)
	at org.jboss.xb.builder.runtime.BeanHandler.startParticle(BeanHandler.java:124)
	at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:630)
	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:401)
	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)

public enum TAvailability
{
   MANDATORY("mandatory"), 
   OPTIONAL("optional");

   private final String value;

   TAvailability(String v)
   {
      value = v;
   }

   public String value()
   {
      return value;
   }

   public static TAvailability fromValue(String v)
   {
      for (TAvailability c : TAvailability.values())
      {
         if (c.value.equals(v))
         {
            return c;
         }
      }
      throw new IllegalArgumentException(v);
   }
}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 06:43:52 2009
From: jira-events at lists.jboss.org (Magesh Kumar B (JIRA))
Date: Fri, 3 Jul 2009 06:43:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-2429) Add support for
	Guest role
In-Reply-To: <249552511.1246617831752.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <500852402.1246617832018.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Magesh Kumar B updated JBPORTAL-2429:
-------------------------------------

        Fix Version/s: 2.8 Final
    Affects Version/s: 2.7.1 Final


> Add support for Guest role
> --------------------------
>
>                 Key: JBPORTAL-2429
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2429
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Security
>    Affects Versions: 2.7.1 Final
>            Reporter: Magesh Kumar B
>             Fix For: 2.8 Final
>
>
> Users would like to see a "Welcome" page for unauthenticated users that disappears once the user is logged in. One way of implementing this is to allow a "Guest" role in JBoss Portal security module and the details of which are explained in the forum link.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 06:43:51 2009
From: jira-events at lists.jboss.org (Magesh Kumar B (JIRA))
Date: Fri, 3 Jul 2009 06:43:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2429) Add support for
	Guest role
Message-ID: <249552511.1246617831752.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add support for Guest role
--------------------------

                 Key: JBPORTAL-2429
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2429
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Security
            Reporter: Magesh Kumar B


Users would like to see a "Welcome" page for unauthenticated users that disappears once the user is logged in. One way of implementing this is to allow a "Guest" role in JBoss Portal security module and the details of which are explained in the forum link.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 08:38:51 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 3 Jul 2009 08:38:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-210) Property order cannot
 be defained on super type
Message-ID: <1151868256.1246624731398.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Property order cannot be defained on super type
-----------------------------------------------

                 Key: JBXB-210
                 URL: https://jira.jboss.org/jira/browse/JBXB-210
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.1.GA
            Reporter: Thomas Diesler


Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Property order is not specified for type org.jboss.osgi.blueprint.parser.xb.TReference bound to a sequence. Property order can be specified using @XmlType.propOrder or @XmlAccessorOrder. List of properties: referenceListeners dependsOn initialization componentName description any interfaceNames otherAttributes timeout filter availability
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.assertPropOrderNotRequired(JBossXBNoSchemaBuilder.java:1278)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1071)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:767)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:523)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:482)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1684)

@XmlType(name = "Treference", namespace = BlueprintContext.XMLNS_BLUEPRINT)
public class TReference extends TServiceReference

@XmlType(name = "TserviceReference", namespace = BlueprintContext.XMLNS_BLUEPRINT, propOrder = { "description" })
public class TServiceReference extends TComponent


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 09:12:51 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 3 Jul 2009 09:12:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-211) @XmlType.propOrder
 required with no schema sequence
Message-ID: <1202136886.1246626771425.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

@XmlType.propOrder required with no schema sequence
---------------------------------------------------

                 Key: JBXB-211
                 URL: https://jira.jboss.org/jira/browse/JBXB-211
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.1.GA
            Reporter: Thomas Diesler


Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Property order is not specified for type or
g.jboss.osgi.blueprint.parser.xb.TRegistrationListener bound to a sequence. Property order can be sp
ecified using @XmlType.propOrder or @XmlAccessorOrder. List of properties: ref refFIXME bean any unr
egistrationMethod registrationMethod reference
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.assertPropOrderNotRequired(JBossXBNoSchemaBuilder.ja
va:1278)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1071)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:767)
	
Please see forum post

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 09:28:03 2009
From: jira-events at lists.jboss.org (Sandeep Vaid (JIRA))
Date: Fri, 3 Jul 2009 09:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-117) Part of
 Composite-Id is foreign Key:How specify in Mapping?
Message-ID: <1444322357.1246627683417.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Part of Composite-Id is foreign Key:How specify in Mapping?
-----------------------------------------------------------

                 Key: HIBERNATE-117
                 URL: https://jira.jboss.org/jira/browse/HIBERNATE-117
             Project: Hibernate
          Issue Type: Feature Request
            Reporter: Sandeep Vaid
            Assignee: Steve Ebersole


 I have 2 classes viz. Product and ProductBasic having one-to-one relationship
  
  class Product{
   String productId;
   ProductBasic productBasic;
   }
   
   class ProductBasic{
    String productId;
    String useCode;
    TimeStamp startTime;
   
    Product product;
   }
   
   Product is mapped to a table PRODUCT which has PRODUCTID as PK.
   ProductBasic is mapped to a table PRODUCTBASIC which has PRODUCTID,USECODE and STARTTTIME as composite key. 
   Also PRODUCTID (of PRODUCTBASIC table) is the foreign key referencing PRODUCT table...
   
  How can i define my one-to-one mapping considering ProductBasic.productId should get its value from Product.productId ?
  
  
  <composite-id>
    <key-property name="productId" column="PRODUCTID" type="string" length="10" />
    <key-property name="useCode" column="USECODE" type="string" length="10" />
    <key-property name="startTime" column="STARTTIME" />
  <composite-id>
  
  In this only productId is the foreign key..
  
  I am aware that i can use a <generator> tag (with class="foreign") inside <composite-id> but i guess it will generate the
  value for entire composite-id and not just a field of it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 09:33:51 2009
From: jira-events at lists.jboss.org (anil kumar (JIRA))
Date: Fri, 3 Jul 2009 09:33:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7075) Communication from
 JSP (scriptlet) to managed bean is not working
Message-ID: <1063056811.1246628031416.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Communication from JSP (scriptlet) to managed bean is not working
-----------------------------------------------------------------

                 Key: JBAS-7075
                 URL: https://jira.jboss.org/jira/browse/JBAS-7075
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Integration
    Affects Versions: JBossAS-5.1.0.GA
         Environment: windows
            Reporter: anil kumar
            Priority: Critical


I am trying to set few parameters from JSP scriptlet. Here is the snippet.HeaderBean is a managed bean with dispalyTitle as setters and getters.
here its printing auditlog,auditlog,auditlog with command link instead of dashboard,transaction,auditlog command link.

HeaderBean  scope is request.

Please suggest me on this.


 <h:form>        
            <%
            ArrayList<String> names = new ArrayList<String>();
            names.add("dashboard");
            names.add("transaction");
            names.add("auditlog");
          %>
        
        <%
       
        HttpServletRequest facesRequest = (HttpServletRequest)FacesContext.getCurrentInstance().getExternalContext().getRequest();
        for (String name: names){                
             HeaderBean header = new HeaderBean();         
            header.setDispalyTitle(name);
            facesRequest.setAttribute("HeaderBean", header);               
        %>               
                <h:commandLink title="#{HeaderBean.dispalyTitle}" value= "#{HeaderBean.dispalyTitle}"> </h:commandLink> <br> 
        <%}%>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 09:31:51 2009
From: jira-events at lists.jboss.org (Sandeep Vaid (JIRA))
Date: Fri, 3 Jul 2009 09:31:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-118) one-to-one with
 composite-id must have common CompositeId class
Message-ID: <68055049.1246627911640.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

one-to-one with composite-id must have common CompositeId class
---------------------------------------------------------------

                 Key: HIBERNATE-118
                 URL: https://jira.jboss.org/jira/browse/HIBERNATE-118
             Project: Hibernate
          Issue Type: Bug
            Reporter: Sandeep Vaid
            Assignee: Steve Ebersole


One query before asking this question: 
I can see 2 different sites for Hibernate Bug Tracking: 
 1) Hibernate JIRA - http://opensource.atlassian.com/projects/hibernate/secure/Dashboard.jspa
 2) JBOSS JIRA- This site
Which is the official site? Out of these 2 sites on which i should post the bugs etc.. ?

I have one-to-one relationship between Product and ProductBasic..

I have Product (PId, PDesc) as composite-key
I have ProductBasic (ProductId, ProductDesc) as composite-Key

Case 1: I created one Composite class which is common for both Product and ProductBasic..
class CompProductRelated{
 string pid;
 string pdesc;
}
then try to fetch Product.. It worked !!!

Case 2: If i create seperate Composite class for Product & ProductBasic viz. CompProduct and CompProductBasic respectively as :

class CompProduct{
 string productId;
 string productDesc;
}

and not if i define the mapping accordingly as:
In Product.hbm.xml
  <composite-id name="compProduct" class="CompProduct">
       <key-property name="pid" type="string" column="PRODUCTID" length="10"></key-property>
       <key-property name="desc" type="string" column="DESC" length="10"></key-property>
     </composite-id>

In ProductBasic.hbm.xml
   <composite-id name="compProductBasic" class="CompProductBasic"> 
   	     <key-property name="productId" column="PRODUCTID" type="string" length="10"/>
   	     <key-property name="productDesc" column="DESC1" type="string" length="10"/>
   	  </composite-id>
Now while fetching Product (and internally it will fetch ProductBasic), it gives the following exception:
org.hibernate.TypeMismatchException: Provided id of the wrong type. Expected: class model.CompProductBasic, got class model.CompProduct

So the only approach for one-to-one with composite-id is to have a common compositeId class..
The link http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#mapping-declaration-compositeid 

recommends 3 solutions (3rd being to have a common compositeId class) but as per my understanding 1st and 2nd approach will give exception for one-to-one with composite-id ...

I think this hibenate restriction (of having common CompositeId class for one-to-one relationship) is not good as it puts a constraint on how domain model (java) should be which could not be possible everytime in legacy applications..

NOTE: This is the similar exception if i don't use a seperate class for CompositeId..
      Hibernate docs have a statement about this situation as :
       Unfortunately, this approach to composite identifiers means that a persistent object is its own identifier. There is no convenient "handle" other than the object itself. You must instantiate an instance of the persistent class itself and populate its identifier properties before you can load() the persistent state associated with a composite key. We call this approach an embedded  composite identifier, and discourage it for serious applications.
      
      A second approach is what we call a mapped composite identifier, where the identifier properties named inside the <composite-id> element are duplicated on both the persistent class and a separate identifier class.
      
      <composite-id class="MedicareId" mapped="true">
              <key-property name="medicareNumber"/>
              <key-property name="dependent"/>
      </composite-id>
      
      
 Useful Links : https://forum.hibernate.org/viewtopic.php?f=1&t=993886

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 09:36:51 2009
From: jira-events at lists.jboss.org (Sandeep Vaid (JIRA))
Date: Fri, 3 Jul 2009 09:36:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-119) one-to-one with
 property-ref always non-lazy
Message-ID: <1718394486.1246628211457.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

one-to-one with property-ref always non-lazy
--------------------------------------------

                 Key: HIBERNATE-119
                 URL: https://jira.jboss.org/jira/browse/HIBERNATE-119
             Project: Hibernate
          Issue Type: Feature Request
            Reporter: Sandeep Vaid
            Assignee: Steve Ebersole


I have one-to-one relationship between Product and ProductBasic.

PRODUCT ------> PRODUCTID(PK)
PRODUCT ------> PID, CODE, STARTTIME (Composite-key) and PID is FK

In product.hbm.xml
 <one-to-one name="productBasic" cascade="save-update" property-ref="activeProduct" constrained="true">
    <formula>PRODUCTID</formula>
 </one-to-one>
 
 
 ProductBasic.hbm.xml as :
 <properties name="activeProduct">
   <many-to-one name="product" class="Product"  insert="false" update="false" lazy="proxy" />
 </properties>
  
  
  When i am using property-ref, and try to load all Products, it fetches ProductBasic also as :
  select * from PRODUCT;   //suppose it return 2 records with productId as 100 and 101 respectively.
  select * from PRODUCTBASIC where productId='100'
  select * from PRODUCTBASIC where productId='101'
 
  How can i fetch ProductBasic in a Non-Lazy manner in this case.


I found few information regarding my problem as :
https://forum.hibernate.org/viewtopic.php?f=25&t=969713

 NOTE: Without property-ref, we can load one-to-one lazily (by sepcifying constrained="true")....... outer-join="true"
  It's shows the message as :
  DEBUG - total objects hydrated: 1
  DEBUG - resolving associations for [model.Product#1]
  DEBUG - loading entity: [model.ProductName#1]
  DEBUG - creating new proxy for entity
  DEBUG - done materializing entity [model.Product#1]
 
  Now the thing now remaining in this is to load one-to-one lazily with property-ref.
  EntityType.resolve() line 382
      if ( isReferenceToPrimaryKey() ) {
 	return resolveIdentifier( (Serializable) value, session );
       }
      else {
        return loadByUniqueKey( getAssociatedEntityName(), uniqueKeyPropertyName, value, session );
       }
     
     and in loadByUniqueKey() method, there is a comment :
     //TODO: implement caching?! proxies?!
     
   I think this is the culprit  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 10:54:51 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 3 Jul 2009 10:54:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-211) @XmlType.propOrder
 required with no schema sequence
In-Reply-To: <1202136886.1246626771425.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1099960275.1246632891454.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBXB-211.
----------------------------------

    Resolution: Rejected
      Assignee: Alexey Loubyansky


The binding is wrong. Sequence is the default model group type.

> @XmlType.propOrder required with no schema sequence
> ---------------------------------------------------
>
>                 Key: JBXB-211
>                 URL: https://jira.jboss.org/jira/browse/JBXB-211
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Thomas Diesler
>            Assignee: Alexey Loubyansky
>
> Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Property order is not specified for type or
> g.jboss.osgi.blueprint.parser.xb.TRegistrationListener bound to a sequence. Property order can be sp
> ecified using @XmlType.propOrder or @XmlAccessorOrder. List of properties: ref refFIXME bean any unr
> egistrationMethod registrationMethod reference
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.assertPropOrderNotRequired(JBossXBNoSchemaBuilder.ja
> va:1278)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1071)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:767)
> 	
> Please see forum post

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 10:26:51 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 3 Jul 2009 10:26:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1009) Prevent merging
 during JOIN/LEAVE processing
Message-ID: <1137846767.1246631211429.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Prevent merging during JOIN/LEAVE processing
--------------------------------------------

                 Key: JGRP-1009
                 URL: https://jira.jboss.org/jira/browse/JGRP-1009
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.9


- Say we have V1={A,B,C} and D joins
- A multicasts the new view V2={A,B,C,D} to {A,B,C} and sends a it via unicast to D
- At time T1, A and C have V2, but B might still have V1
- At timeT3 B will also have V2
- HOWEVER, *before* T3 (at T2), A's MERGE functionality gets the current views and discovers the discrepancy
- A will now initiate a merge. This is superfluous because B would have received V2 at T3 (maybe a few ms later) !

This is not incorrect, but we still want to prevent spurious merges.

SOLUTION:
- Turn off merging during view change processing
- This can be done via discarding of MERGE events at GMS during view processing, or by disabling merging directly in MERGE2, MERGE3, MERGEFAST. The first option looks more promising, as it requires only 1 hange in GMS

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 10:46:51 2009
From: jira-events at lists.jboss.org (deckrider deckrider (JIRA))
Date: Fri, 3 Jul 2009 10:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-1121) Client
 SocketFactory should be configurable by InvokerLocator
In-Reply-To: <31741702.1239943414266.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1316358662.1246632411548.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBREM-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474838#action_12474838 ] 

deckrider deckrider commented on JBREM-1121:
--------------------------------------------

I see me earlier comment was incomplete.

So I've upgraded to remoting 2.2.3 and added this configuration to jboss-4.2.3.GA/server/default/deploy/ejb3.deployer/META-INF/jboss-service.xml:

   <mbean code="org.jboss.remoting.transport.Connector"
          name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3">
      <depends>jboss.aop:service=AspectDeployer</depends>
      <attribute name="InvokerLocator"><![CDATA[sslsocket://${jboss.bind.address}:3873/?org.jboss.remoting.Remoting.useAllSocketFactoryParams=true&org.jboss.remoting.serverAuthMode=false]]></attribute>
      <attribute name="Configuration">
         <handlers>
            <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>
         </handlers>
      </attribute>
   </mbean>

However, it is not working.  Can anyone help please?

> Client SocketFactory should be configurable by InvokerLocator
> -------------------------------------------------------------
>
>                 Key: JBREM-1121
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1121
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.2.SP11, 2.5.1 (Flounder)
>            Reporter: Ron Sigal
>            Assignee: Ron Sigal
>             Fix For: 2.2.3, 2.5.2 (Flounder)
>
>
> org.jboss.remoting.RemoteClientInvoker, which creates the client invoker's SocketFactory, uses only the parameters passed in the configuration map (except for looking in the InvokerLocator for org.jboss.remoting.SOCKET_FACTORY_CLASS_NAME (actual value "socketFactoryClassName"), which was introduced in JBREM-1014 "Support injection of socket factory class name into AbstractInvoker").  There should be a configurable option to use all parameters from the InvokerLocator.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 11:00:51 2009
From: jira-events at lists.jboss.org (deckrider deckrider (JIRA))
Date: Fri, 3 Jul 2009 11:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-1121) Client
 SocketFactory should be configurable by InvokerLocator
In-Reply-To: <31741702.1239943414266.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2111600095.1246633251710.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBREM-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474840#action_12474840 ] 

deckrider deckrider commented on JBREM-1121:
--------------------------------------------

Never mind, the following works:

<attribute name="InvokerLocator"><![CDATA[sslsocket://${jboss.bind.address}:3873/?useAllSocketFactoryParams=true&org.jboss.remoting.serverAuthMode=false]]></attribute>


> Client SocketFactory should be configurable by InvokerLocator
> -------------------------------------------------------------
>
>                 Key: JBREM-1121
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1121
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.2.SP11, 2.5.1 (Flounder)
>            Reporter: Ron Sigal
>            Assignee: Ron Sigal
>             Fix For: 2.2.3, 2.5.2 (Flounder)
>
>
> org.jboss.remoting.RemoteClientInvoker, which creates the client invoker's SocketFactory, uses only the parameters passed in the configuration map (except for looking in the InvokerLocator for org.jboss.remoting.SOCKET_FACTORY_CLASS_NAME (actual value "socketFactoryClassName"), which was introduced in JBREM-1014 "Support injection of socket factory class name into AbstractInvoker").  There should be a configurable option to use all parameters from the InvokerLocator.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 12:09:51 2009
From: jira-events at lists.jboss.org (Dieter Cailliau (JIRA))
Date: Fri, 3 Jul 2009 12:09:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1068) @Interceptors
 defined on
 @Service EJBs do not have @PostConstruct @PreDestroy interceptor methods
 invoked
In-Reply-To: <18924421.1192225863309.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1121057709.1246637391579.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474850#action_12474850 ] 

Dieter Cailliau commented on EJBTHREE-1068:
-------------------------------------------

I could not get the workaround working for the start() method: the @AroundInvoke never intercepts start(), no matter in which interface it was. This means that i can not use my resources (injected by my interceptor) in the start() implementation of the service, since start() is ran without interception, and always the first call on that service. (jboss 4.2.3) Therefore this workaround isn't of much use to me: i have to call Injector.inject(this) myself in the first line of my start() implementation.


> @Interceptors defined on @Service EJBs do not have @PostConstruct @PreDestroy interceptor methods invoked
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1068
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1068
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>    Affects Versions: AS 4.2.1.GA
>            Reporter: Michael McKibben
>
> I've defined an injection-style interceptor class that needs to be called before a @Service EJBs start() method is invoked on service startup. Using @PostConstruct doesn't not work (the container never calls my @PostConstruct annotated method). @AroundInvoke only works for methods defined on the @Local or @Remote business interface, not the @Management interface.
> Shouldn't @PostConstruct and @PreDestroy be invoked on @Service EJBs? I need my interceptor to behave like the standard injection interceptors do.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 08:38:51 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 3 Jul 2009 08:38:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-210) Property order cannot
 be defined on super type
In-Reply-To: <1151868256.1246624731398.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <698786112.1246624731446.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler updated JBXB-210:
--------------------------------

    Summary: Property order cannot be defined on super type  (was: Property order cannot be defained on super type)


> Property order cannot be defined on super type
> ----------------------------------------------
>
>                 Key: JBXB-210
>                 URL: https://jira.jboss.org/jira/browse/JBXB-210
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Thomas Diesler
>
> Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Property order is not specified for type org.jboss.osgi.blueprint.parser.xb.TReference bound to a sequence. Property order can be specified using @XmlType.propOrder or @XmlAccessorOrder. List of properties: referenceListeners dependsOn initialization componentName description any interfaceNames otherAttributes timeout filter availability
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.assertPropOrderNotRequired(JBossXBNoSchemaBuilder.java:1278)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1071)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:767)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:523)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:482)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1684)
> @XmlType(name = "Treference", namespace = BlueprintContext.XMLNS_BLUEPRINT)
> public class TReference extends TServiceReference
> @XmlType(name = "TserviceReference", namespace = BlueprintContext.XMLNS_BLUEPRINT, propOrder = { "description" })
> public class TServiceReference extends TComponent

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 23:00:51 2009
From: jira-events at lists.jboss.org (Ray Ploski (JIRA))
Date: Fri, 3 Jul 2009 23:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-86) Reduce logging noise
 by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1052198926.1246676451461.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ray Ploski updated JBBOOT-86:
-----------------------------

    Attachment: JBBOOT86.patch


Adding the patch this time for real.

> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Andrew Lee Rubinger
>         Attachments: JBBOOT86.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul  4 02:32:51 2009
From: jira-events at lists.jboss.org (Ray Ploski (JIRA))
Date: Sat, 4 Jul 2009 02:32:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-86) Reduce logging noise
 by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1110014445.1246689171453.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ray Ploski updated JBBOOT-86:
-----------------------------

    Attachment: JBBOOT86-2.patch


JBBOOT86-2.patch uploaded based upon comments.

> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Andrew Lee Rubinger
>         Attachments: JBBOOT86-2.patch, JBBOOT86.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul  4 12:58:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Sat, 4 Jul 2009 12:58:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-86) Reduce logging
 noise by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <878126092.1246726731699.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-86.
---------------------------------------

    Fix Version/s: 2.0.0-beta-1 
       Resolution: Done


> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-as
>            Reporter: Max Rydahl Andersen
>            Assignee: Ray Ploski
>             Fix For: 2.0.0-beta-1 
>
>         Attachments: JBBOOT86-3.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul  4 12:09:51 2009
From: jira-events at lists.jboss.org (Ray Ploski (JIRA))
Date: Sat, 4 Jul 2009 12:09:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-86) Reduce logging noise
 by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1985268164.1246723791577.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ray Ploski updated JBBOOT-86:
-----------------------------

    Attachment: JBBOOT86-3.patch


Logging output provides:

	$JBOSS_HOME URL: file:/opt/jems/jbossas/jboss-dev
	Bootstrap: $JBOSS_HOME/server/default/conf/bootstrap.xml
	Common Base: $JBOSS_HOME/common/
	Common Library: $JBOSS_HOME/common/lib/
	Server Name: default
	Server Base: $JBOSS_HOME/server/
	Server Library: $JBOSS_HOME/server/default/lib/
	Server Config: $JBOSS_HOME/server/default/conf/
	Server Home: $JBOSS_HOME/server/default/
	Server Data: $JBOSS_HOME/server/default/data/
	Server Log: $JBOSS_HOME/server/default/log/
	Server Temp: $JBOSS_HOME/server/default/tmp/

Notes:
* the method getPath has been renamed to getRelativePath to better describe function after modifications.
* "$" has been prepended to the relative paths
* File.seperatorChar has been introduced to replace the "/" string in the output.

* StringBuffer has been replaced with StringBuilder in the logServerInfo method

> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Ray Ploski
>         Attachments: JBBOOT86-2.patch, JBBOOT86-3.patch, JBBOOT86.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul  4 12:11:51 2009
From: jira-events at lists.jboss.org (Ray Ploski (JIRA))
Date: Sat, 4 Jul 2009 12:11:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-86) Reduce logging noise
 by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <426675487.1246723911661.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ray Ploski updated JBBOOT-86:
-----------------------------

    Attachment:     (was: JBBOOT86.patch)


> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Ray Ploski
>         Attachments: JBBOOT86-3.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 21:49:51 2009
From: jira-events at lists.jboss.org (Ray Ploski (JIRA))
Date: Fri, 3 Jul 2009 21:49:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-86) Reduce logging noise
 by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <327168236.1246672191449.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ray Ploski updated JBBOOT-86:
-----------------------------

    Attachment: JBBOOT86.diff


Hi! I'm uploading a patch that should resolve the issue.  When you are sure the patch will bring no harm to you, execute the following command at the base of your svn project for bootstrap:

patch -p0 -i ~/JBBOOT86.diff

> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Andrew Lee Rubinger
>         Attachments: JBBOOT86.diff
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul  4 16:11:51 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Sat, 4 Jul 2009 16:11:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7076) DeploymentTemplate
 temp file url is not escaped properly
Message-ID: <1147631592.1246738311392.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

DeploymentTemplate temp file url is not escaped properly
--------------------------------------------------------

                 Key: JBAS-7076
                 URL: https://jira.jboss.org/jira/browse/JBAS-7076
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Scott M Stark
            Assignee: Scott M Stark


The DsDataSourceTemplate applyTemplate method is creating a temp file, but somewhere the file url is not being properly escaped (at least on mac os x), as a temp file name of

/var/folders/jY/jY1BDqLkHKO+a4nm+GooZE+++TI/-Tmp-/DsDataSourceTemplate9162352335796065232-ds.xml

is created, but when the file is accessed by the vfs, it fails with:

java.io.FileNotFoundException: /var/folders/jY/jY1BDqLkHKO a4nm GooZE   TI/-Tmp-/DsDataSourceTemplate9162352335796065232-ds.xml



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul  4 12:58:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Sat, 4 Jul 2009 12:58:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-86) Reduce logging noise
 by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <574592917.1246726731845.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated JBBOOT-86:
--------------------------------------

    Component/s: impl-as


> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-as
>            Reporter: Max Rydahl Andersen
>            Assignee: Ray Ploski
>             Fix For: 2.0.0-beta-1 
>
>         Attachments: JBBOOT86-3.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul  3 22:58:51 2009
From: jira-events at lists.jboss.org (Ray Ploski (JIRA))
Date: Fri, 3 Jul 2009 22:58:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-86) Reduce logging noise
 by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1987347357.1246676331443.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ray Ploski updated JBBOOT-86:
-----------------------------

    Attachment:     (was: JBBOOT86.diff)


> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Andrew Lee Rubinger
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul  4 16:01:52 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Sat, 4 Jul 2009 16:01:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7050)
 "ClassNotFoundException:
 org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote
 calls to ManagementView.getTemplate()
Message-ID: <1888652206.1246737712000.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-7050.
---------------------------------

    Resolution: Done


The template info server classes are now using writeReplace to only return BasicDeploymentTemplateInfo class.


> "ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote calls to ManagementView.getTemplate()
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7050
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7050
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to create a datasource in AS5 using JON, the following exception occurs:
> java.lang.ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo                                                                                               
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)                                                                                            
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)                                                                                                 
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)                                                                                                                         
>         at java.lang.Class.forName0(Native Method)                                                                                                                                               
>         at java.lang.Class.forName(Class.java:247)                                                                                                                                               
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)                                                                   
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)                                                                                                               
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)                                                                                                                  
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)                                                                                                  
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)                                                                                                               
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)                                                                                                              
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)                                                                                                                 
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)                                                        
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)                                                                  
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)                                                                              
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)                                                                                     
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)                                                                        
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)                                                                             
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)                                                                                                 
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                                    
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                                     
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                            
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                          
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                        
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)                                                                                                                
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)                                                             
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> I was only able to find this class in jboss-embedded-all maven module.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul  4 01:31:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Sat, 4 Jul 2009 01:31:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBOOT-86) Reduce logging
 noise by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1094274044.1246685511447.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474868#action_12474868 ] 

Andrew Lee Rubinger commented on JBBOOT-86:
-------------------------------------------

Forums are down ATM, so I'll do my peer review of the patch discussion here. ;)

1) The patch fails the TestSuite with NPEs.  Check the development instructions: http://www.jboss.org/community/wiki/JBossBootstrapDevelopmentandContribution 

2) This line:

	  // Log full paths when log level Trace is enabled.
      if (log.isTraceEnabled()) 
      {
	    return url.toExternalForm();
      }

...I don't like due to the conditional logic depending upon this log level.  Essentially this creates a case where the test output (with logging set to TRACE) is different than in other environments, and the rest of the method doesn't get tested.  So I'd skip this step.

Let's take another look with those two issues addressed?  Awesome to see your contribution Ray, thanks for getting involved.

> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Andrew Lee Rubinger
>         Attachments: JBBOOT86.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul  4 11:06:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Sat, 4 Jul 2009 11:06:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBOOT-86) Reduce logging
 noise by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <289412612.1246720011757.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger reassigned JBBOOT-86:
-----------------------------------------

    Assignee: Ray Ploski  (was: Andrew Lee Rubinger)


> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Ray Ploski
>         Attachments: JBBOOT86-2.patch, JBBOOT86.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul  4 11:20:51 2009
From: jira-events at lists.jboss.org (Luca Stancapiano (JIRA))
Date: Sat, 4 Jul 2009 11:20:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2430) drag and drop
 and partial refresh in a region
Message-ID: <1129829044.1246720851383.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

drag and drop and partial refresh in a region
---------------------------------------------

                 Key: JBPORTAL-2430
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2430
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Core, Portal Theme
    Affects Versions: 2.7.2 Final
         Environment: JBoss Portal 2.7.2 in JBoss 4.2.3 and JBoss 5.1
            Reporter: Luca Stancapiano
             Fix For: 2.8 Final


hi... I added new properties inside the region. With this patch we can decide what region can use partial refresh or drag and drop feature. I've seen that this part is managed in the core but we cannot configure le sngle region for theese properties, so we was forced to use those properties in all the page. I added the two new properties in the org.jboss.portal.theme.tag.RegionTagHandler tag class:


    private String dndEnabled = null;
    private String partialRefreshEnabled = null;

	/**
	 * Attribute handler for the drag and drop of this tag
	 * <p>
	 * This field enables drag and drop on a chosen region
	 * </p>
	 * 
	 * @param dndEnabled
	 *            it can be true or false
	 */
	public void setDndEnabled(String dndEnabled) {
		this.dndEnabled = dndEnabled;
	}

    /**
     * Attribute handler for the partial refresh of this tag
     * <p>
     * This field enables partial refresh on a chosen region
     * </p>
     * 
     * @param partialRefreshEnabled
     *            it can be true or false
     */
    public void setPartialRefreshEnabled(String partialRefreshEnabled) {
        this.partialRefreshEnabled = partialRefreshEnabled;
    }




and this part inside the doTag() method:


			
	    if (dndEnabled != null)
		rrc.getProperties().put(DynaRenderOptions.DND_ENABLED,
		      dndEnabled);
            
            if (partialRefreshEnabled != null)
                rrc.getProperties().put(DynaRenderOptions.PARTIAL_REFRESH_ENABLED,
                      partialRefreshEnabled);



I also updated tag descriptor portal-layout.tld inside core and theme projects adding the new properties:

<taglib
   xmlns="http://java.sun.com/xml/ns/j2ee"
   xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd"
   version="2.0">
   <tlib-version>1.0</tlib-version>
   <jsp-version>2.0</jsp-version>
   <short-name></short-name>
   <uri>http://www.jboss.org/portal</uri>
   <tag>
      <name>region</name>
      <tag-class>org.jboss.portal.theme.tag.RegionTagHandler</tag-class>
      <body-content>empty</body-content>
      <attribute>
         <name>orientation</name>
      </attribute>
      <attribute>
         <name>regionName</name>
      </attribute>
      <attribute>
         <name>regionID</name>
      </attribute>

<---------------------------------------
      <attribute>
         <name>dndEnabled</name>
      </attribute>
      <attribute>
         <name>partialRefreshEnabled</name>
      </attribute>

------------------------------------------
   </tag>





Now, when we want that only some regions uses this properties we can do inside our layout jsp something as:

<p:region regionName='left' regionID='regionA' dndEnabled='true' partialRefreshEnabled='false'/>

If we don't specify that two properties, the region will take the properties of the parent node as well as 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul  4 11:00:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Sat, 4 Jul 2009 11:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBOOT-86) Reduce logging
 noise by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <780247875.1246719651904.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12474888#action_12474888 ] 

Andrew Lee Rubinger commented on JBBOOT-86:
-------------------------------------------

This "JBBOOT86-2.patch" is good. :)

Leaves form:

        JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/projects/bootstrap/trunk/impl-as/target/tests-classes/jbossas/
	Bootstrap: JBOSS_HOME/server/default/conf/bootstrap.xml
	Common Base: JBOSS_HOME/common/
	Common Library: JBOSS_HOME/common/lib/
	Server Name: default
	Server Base: JBOSS_HOME/server/
	Server Library: JBOSS_HOME/server/default/lib/
	Server Config: JBOSS_HOME/server/default/conf/
	Server Home: JBOSS_HOME/server/default/
	Server Data: JBOSS_HOME/server/default/data
	Server Log: JBOSS_HOME/server/default/log
	Server Temp: JBOSS_HOME/server/default/tmp

Some minor notes:

1) Let's prepend a "$" to the cut path, make into "$JBOSS_HOME"
2) Can "getPath" be something a bit more descriptive?  "getRelativePath(String base,URL actual )" perhaps?
3) The "/" in "getPath" should be File.separatorChar so we're not OS-specific

...then we'll have Ray do the honors of a commit.  Just put "JBBOOT-86" somewhere in the commit message.

> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Andrew Lee Rubinger
>         Attachments: JBBOOT86-2.patch, JBBOOT86.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul  4 12:11:51 2009
From: jira-events at lists.jboss.org (Ray Ploski (JIRA))
Date: Sat, 4 Jul 2009 12:11:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-86) Reduce logging noise
 by making file/urls' relative
In-Reply-To: <14257488.1243403038706.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1890814077.1246723911551.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ray Ploski updated JBBOOT-86:
-----------------------------

    Attachment:     (was: JBBOOT86-2.patch)


> Reduce logging noise by making file/urls' relative
> --------------------------------------------------
>
>                 Key: JBBOOT-86
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-86
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>            Reporter: Max Rydahl Andersen
>            Assignee: Ray Ploski
>         Attachments: JBBOOT86-3.patch
>
>
> > In some effort to address frequent user feedback that our logging is difficult to weed through, I'm considering changing the server info dump to something like:
> >
> > 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> >
> >     Bootstrap URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/bootstrap.xml
> >     JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> >     Common Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/
> >     Common Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/common/lib/
> >     Server Name: default
> >     Server Base URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/
> >     Server Library URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/lib/
> >     Server Config URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/conf/
> >     Server Home URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/
> >     Server Data URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/data
> >     Server Log URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/log/
> >     Server Temp URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/server/default/tmp
> >
> > Do we like the additional whitespace to separate this stuff out from the rest?  We've done a similar thing in EJB3 where we print out the target JNDI names.
> >
> > Ultimately we should probably look at each INFO statement on AS boot and decide if it should really be there or not. 
> Any chance you could print these as *relative* locations to i.e. current working directory or HOME_URL instead of full canonical names which is very redundant and hard to read ?
> i.e., using JBOSS_HOME_URL as base: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> 12:02:08,263 INFO  [JBossASServerImpl] Server Configuration:
> JBOSS_HOME URL: file:/home/alrubinger/business/jboss/wc/jbossas/branches/Branch_5_x_BootstrapLegacyRemoval/build/output/jboss-5.1.0.GA/
> Bootstrap: server/default/conf/bootstrap.xml
> Common Base: common/
> Common Library: common/lib/
> Server Name: default
> Server Base: server/
> Server Library: server/default/lib/
> Server Config: default/conf/
> Server Home: server/default/
> Server Data: server/default/data
> Server Log: default/log/
> Server Temp: default/tmp
> Note, that I removed the redundant URL for those that aren't necessarily full url's when printed like this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jul  5 12:39:51 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Sun, 5 Jul 2009 12:39:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-288) Errors show up in
	problems view
In-Reply-To: <13325945.1231384923985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <713252756.1246811991401.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-288.
---------------------------

    Resolution: Done


> Errors show up in problems view
> -------------------------------
>
>                 Key: GPD-288
>                 URL: https://jira.jboss.org/jira/browse/GPD-288
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>            Priority: Critical
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Process errors (e.g. duplicate node names) should show up in the problems view and should have the 'problem' annotation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jul  5 15:15:51 2009
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Sun, 5 Jul 2009 15:15:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1863) res-type in
 resource-ref is not checked
In-Reply-To: <2026359205.1246559811397.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <993243095.1246821351652.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolfgang Knauf updated EJBTHREE-1863:
-------------------------------------

    Attachment: ResourceRef.ear


Version 2 of the sample, with two more "java:/comp/EJBContext" bindings through "<resource-env-ref>", one with injection, the other with a lookup.

It shows that for a "<resource-env-ref>", the "<resource-env-ref-type>" is not validated against the type of the JNDI lookup result, it is just checked that the class can be found in the current classloader.

So, the final goal should probably be to make "resource-env-ref" and "resource-ref" use the same validation code.

A side effect of my sample is that it works around https://jira.jboss.org/jira/browse/EJBTHREE-1858 , because 1858 first checks the type, then performs some specific actions according to the type, and the type does not match in my sample.

> res-type in resource-ref is not checked
> ---------------------------------------
>
>                 Key: EJBTHREE-1863
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1863
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.7
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>         Attachments: ResourceRef.ear, ResourceRef.ear
>
>
> The "res-type" of the "resource-ref" element in ejb-jar.xml is not verified.
> See the attached sample: neither on deploy nor on JNDI lookup, an error is raised for this xml snippet, which contains an invalid res-type:
> 			<resource-ref>
> 				<res-ref-name>EnvNameOfSessionContext1</res-ref-name>
>  				<res-type>whole.lotta.Crap</res-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 				<injection-target>
> 					<injection-target-class>de.knauf.resourceref.ResourceRefTestBean</injection-target-class>
> 					<injection-target-name>sessionContext1</injection-target-name>
> 			  	</injection-target>
> 			</resource-ref>
> 			<resource-ref>
> 				<res-ref-name>EnvNameOfSessionContext2</res-ref-name>
>  				<res-type>whole.lotta.Crap</res-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 			</resource-ref>
> The class org.jboss.injection.ResourceHandler.loadXmlResourceRefs almost completely ignores the "res-type" element ;-).
> For a "resource-env-ref" element, the "resource-env-ref-type" is validated, though maybe this happens by accident ;-):
> Caused by: java.lang.ClassNotFoundException: asdjavax.ejb.SessionContext from BaseClassLoader at 22adfd{...}
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:448)
> 	at java.lang.ClassLoader.loadClass(Unknown Source)
> 	at java.lang.ClassLoader.loadClassInternal(Unknown Source)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Unknown Source)
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceEnvRefs(ResourceHandler.java:217)
> 	... 73 more
> So, I would like a similar check for the "resource-ref" res-type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jul  5 17:52:51 2009
From: jira-events at lists.jboss.org (Vasile Alaiba (JIRA))
Date: Sun, 5 Jul 2009 17:52:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-741) Issues with
	aophelper.bat
Message-ID: <1981652518.1246830771395.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Issues with aophelper.bat 
--------------------------

                 Key: JBAOP-741
                 URL: https://jira.jboss.org/jira/browse/JBAOP-741
             Project: JBoss AOP
          Issue Type: Patch
      Security Level: Public (Everyone can see)
    Affects Versions: 2.1.3.GA
            Reporter: Vasile Alaiba
            Priority: Trivial


aophelper.bat does not work if spaces are part of the path. It also has some issues setting up the CLASSPATH.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jul  5 17:54:51 2009
From: jira-events at lists.jboss.org (Vasile Alaiba (JIRA))
Date: Sun, 5 Jul 2009 17:54:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-741) Issues with
	aophelper.bat
In-Reply-To: <1981652518.1246830771395.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <213282560.1246830891402.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAOP-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vasile Alaiba updated JBAOP-741:
--------------------------------

    Attachment: aophelper.bat


> Issues with aophelper.bat 
> --------------------------
>
>                 Key: JBAOP-741
>                 URL: https://jira.jboss.org/jira/browse/JBAOP-741
>             Project: JBoss AOP
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.3.GA
>            Reporter: Vasile Alaiba
>            Priority: Trivial
>         Attachments: aophelper.bat
>
>
> aophelper.bat does not work if spaces are part of the path. It also has some issues setting up the CLASSPATH.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 02:59:51 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 6 Jul 2009 02:59:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMETA-213) add JCA DTD files
In-Reply-To: <2485970.1245738836463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <307840146.1246863591485.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang reopened JBMETA-213:
-------------------------------



update dtd files and add testcase

> add JCA DTD files
> -----------------
>
>                 Key: JBMETA-213
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-213
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.2.Beta2, 2.0.0.CR1
>
>
> add connector_1_5.dtd and connector_1_6.dtd into metadata/trunk and metadata/rar

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 03:50:03 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 6 Jul 2009 03:50:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMETA-213) add JCA DTD files
In-Reply-To: <2485970.1245738836463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1818254747.1246866603910.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMETA-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved JBMETA-213.
-------------------------------

    Fix Version/s:     (was: 1.0.2.Beta2)
       Resolution: Done


> add JCA DTD files
> -----------------
>
>                 Key: JBMETA-213
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-213
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 2.0.0.CR1
>
>
> add connector_1_5.dtd and connector_1_6.dtd into metadata/trunk and metadata/rar

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 05:16:52 2009
From: jira-events at lists.jboss.org (Nicolas Karageuzian (JIRA))
Date: Mon, 6 Jul 2009 05:16:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7077) ant <jmx> raise
 BuildException for attribute reading error
Message-ID: <2019489997.1246871812125.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

ant <jmx> raise BuildException for attribute reading error
----------------------------------------------------------

                 Key: JBAS-7077
                 URL: https://jira.jboss.org/jira/browse/JBAS-7077
             Project: JBoss Application Server
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-4.0.4.GA
         Environment: All
            Reporter: Nicolas Karageuzian
            Priority: Trivial


add failonerror on <jmx> ant task to perform monitoring without stopping whole ant script while MBean doesn't exists.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 05:21:51 2009
From: jira-events at lists.jboss.org (Nicolas Karageuzian (JIRA))
Date: Mon, 6 Jul 2009 05:21:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7077) ant <jmx> raise
 BuildException for attribute reading error
In-Reply-To: <2019489997.1246871812125.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <911935227.1246872111896.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nicolas Karageuzian updated JBAS-7077:
--------------------------------------

    Attachment: JMXTask.diff


Here is my diff for an optional boolean failonerror attribute, and modifications within execute for error handling.

It affects org.jboss.ant.JMX and helps for monitoring many attributes on many MBeans on many instances with an ant script in a single JVM (versus twiddle which instanciate 1 JVM per instance per MBean).

> ant <jmx> raise BuildException for attribute reading error
> ----------------------------------------------------------
>
>                 Key: JBAS-7077
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7077
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: All
>            Reporter: Nicolas Karageuzian
>            Priority: Trivial
>         Attachments: JMXTask.diff
>
>
> add failonerror on <jmx> ant task to perform monitoring without stopping whole ant script while MBean doesn't exists.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 07:39:51 2009
From: jira-events at lists.jboss.org (Aleksander Adamowski (JIRA))
Date: Mon, 6 Jul 2009 07:39:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1864) Release source
 and javadoc artifacts to Maven repositories
Message-ID: <1250424755.1246880391385.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Release source and javadoc artifacts to Maven repositories
----------------------------------------------------------

                 Key: EJBTHREE-1864
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1864
             Project: EJB 3.0
          Issue Type: Release
          Components: build
    Affects Versions: trunk
            Reporter: Aleksander Adamowski


Currently, most Maven 2 artifacts are released without accompanying source and javadoc artifacts, e.g.:

http://repository.jboss.com/maven2/jboss/jboss-annotations-ejb3/4.2.3.GA/

It would make development work much simpler if the release deployment procedure included source and javadoc.

With Maven 2, this is trivial:

http://maven.apache.org/plugin-developers/cookbook/attach-source-javadoc-artifacts.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 09:15:59 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 6 Jul 2009 09:15:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1864) Release source
 and javadoc artifacts to Maven repositories
In-Reply-To: <1250424755.1246880391385.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1734047099.1246886159948.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved EJBTHREE-1864.
-------------------------------------------

    Resolution: Rejected
      Assignee: Andrew Lee Rubinger


We've got JavaDoc and Source attachments for the EJB3 releases; everything is under the org.jboss.ejb3 groupId namespace.  For example:


> Release source and javadoc artifacts to Maven repositories
> ----------------------------------------------------------
>
>                 Key: EJBTHREE-1864
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1864
>             Project: EJB 3.0
>          Issue Type: Release
>          Components: build
>    Affects Versions: trunk
>            Reporter: Aleksander Adamowski
>            Assignee: Andrew Lee Rubinger
>
> Currently, most Maven 2 artifacts are released without accompanying source and javadoc artifacts, e.g.:
> http://repository.jboss.com/maven2/jboss/jboss-annotations-ejb3/4.2.3.GA/
> It would make development work much simpler if the release deployment procedure included source and javadoc.
> With Maven 2, this is trivial:
> http://maven.apache.org/plugin-developers/cookbook/attach-source-javadoc-artifacts.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 09:16:00 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 6 Jul 2009 09:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1864) Release source
 and javadoc artifacts to Maven repositories
In-Reply-To: <1250424755.1246880391385.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <721829908.1246886160062.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated EJBTHREE-1864:
------------------------------------------

    Comment: was deleted


> Release source and javadoc artifacts to Maven repositories
> ----------------------------------------------------------
>
>                 Key: EJBTHREE-1864
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1864
>             Project: EJB 3.0
>          Issue Type: Release
>          Components: build
>    Affects Versions: trunk
>            Reporter: Aleksander Adamowski
>            Assignee: Andrew Lee Rubinger
>
> Currently, most Maven 2 artifacts are released without accompanying source and javadoc artifacts, e.g.:
> http://repository.jboss.com/maven2/jboss/jboss-annotations-ejb3/4.2.3.GA/
> It would make development work much simpler if the release deployment procedure included source and javadoc.
> With Maven 2, this is trivial:
> http://maven.apache.org/plugin-developers/cookbook/attach-source-javadoc-artifacts.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 09:16:00 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 6 Jul 2009 09:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1864) Release source
 and javadoc artifacts to Maven repositories
In-Reply-To: <1250424755.1246880391385.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <835857373.1246886160187.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475008#action_12475008 ] 

Andrew Lee Rubinger commented on EJBTHREE-1864:
-----------------------------------------------

We've got JavaDoc and Source attachments for the EJB3 releases; everything is under the org.jboss.ejb3 groupId namespace. For example: 

http://repository.jboss.org/maven2/org/jboss/ejb3/jboss-ejb3-ext-api/1.0.0/

> Release source and javadoc artifacts to Maven repositories
> ----------------------------------------------------------
>
>                 Key: EJBTHREE-1864
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1864
>             Project: EJB 3.0
>          Issue Type: Release
>          Components: build
>    Affects Versions: trunk
>            Reporter: Aleksander Adamowski
>            Assignee: Andrew Lee Rubinger
>
> Currently, most Maven 2 artifacts are released without accompanying source and javadoc artifacts, e.g.:
> http://repository.jboss.com/maven2/jboss/jboss-annotations-ejb3/4.2.3.GA/
> It would make development work much simpler if the release deployment procedure included source and javadoc.
> With Maven 2, this is trivial:
> http://maven.apache.org/plugin-developers/cookbook/attach-source-javadoc-artifacts.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 09:40:52 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 6 Jul 2009 09:40:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-105) SJC/RAdeployer: Add
 support for DTDs
Message-ID: <1880250736.1246887652072.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC/RAdeployer: Add support for DTDs
------------------------------------

                 Key: JBJCA-105
                 URL: https://jira.jboss.org/jira/browse/JBJCA-105
             Project: JBoss JCA
          Issue Type: Task
          Components: Deployer
    Affects Versions: 1.0.0.Alpha1
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha2


Add dtd deployment into sjc deployer

create this task for tacking this function. code commit r90827 should belong this task

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 09:56:51 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 6 Jul 2009 09:56:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-105) SJC/RAdeployer: Add
 support for DTDs
In-Reply-To: <1880250736.1246887652072.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1054605650.1246888611414.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang updated JBJCA-105:
-----------------------------

    Affects Version/s:     (was: 1.0.0.Alpha1)


> SJC/RAdeployer: Add support for DTDs
> ------------------------------------
>
>                 Key: JBJCA-105
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-105
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> Add dtd deployment into sjc deployer
> create this task for tacking this function. code commit r90827 should belong this task

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 10:17:51 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 6 Jul 2009 10:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1954502403.1246889871735.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky reassigned JBXB-206:
--------------------------------------

    Assignee: Alexey Loubyansky


What I meant is that the issue is probably the resolver is not configured properly. It's not enough to just instantiate it. What namespace is resolved with XsdBinder?

> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>            Assignee: Alexey Loubyansky
>         Attachments: jboss-profiler.properties, jbossxb.zip, server.log.gz
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 10:45:51 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Mon, 6 Jul 2009 10:45:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7078) Create
 SSLSocketFactory that uses a JaasSecurityDomain
Message-ID: <565179297.1246891551731.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Create SSLSocketFactory that uses a JaasSecurityDomain
------------------------------------------------------

                 Key: JBAS-7078
                 URL: https://jira.jboss.org/jira/browse/JBAS-7078
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Marcus Moyses
            Assignee: Marcus Moyses
             Fix For: JBossAS-5.2.0.Beta1


We need a SSLSocketFactory with a default constructor and a static getDefault method that sets up SSL using a JaasSecurityDomain mbean so it can be used for LDAPS, Remoting, etc.
The name of the security domain must be set as a system property.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 11:07:51 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:07:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-355) offer conversion
 support for files from jBPM 3 to jBPM 4
Message-ID: <1159827641.1246892871401.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

offer conversion support for files from jBPM 3 to jBPM 4
--------------------------------------------------------

                 Key: GPD-355
                 URL: https://jira.jboss.org/jira/browse/GPD-355
             Project: JBoss jBPM GPD
          Issue Type: Task
          Components: jpdl
            Reporter: Koen Aers
            Assignee: Koen Aers
            Priority: Minor
             Fix For: jBPM jPDL Designer 4.0.0.GA




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 11:10:05 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:10:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-355) offer conversion
 support for files from jBPM 3 to jBPM 4
In-Reply-To: <1159827641.1246892871401.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1220191639.1246893005688.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-355:
--------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)


> offer conversion support for files from jBPM 3 to jBPM 4
> --------------------------------------------------------
>
>                 Key: GPD-355
>                 URL: https://jira.jboss.org/jira/browse/GPD-355
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.0.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 11:10:05 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:10:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-301) migration support
In-Reply-To: <17851186.1235491064707.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <216104807.1246893005573.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-301.
---------------------------

    Resolution: Done


The optional part is now issue GPD-355

> migration support
> -----------------
>
>                 Key: GPD-301
>                 URL: https://jira.jboss.org/jira/browse/GPD-301
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>
> things like:
> * make sure that we can work with jBPM 3 and jBPM 4 process files in a single eclipse installation
> * make sure that the files are associated to the correct version of the editor
> * optional: offer conversion support for files

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 11:17:51 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-336) image generation
	fails
In-Reply-To: <18908917.1242894356480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1697491408.1246893471964.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/GPD-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475051#action_12475051 ] 

Koen Aers commented on GPD-336:
-------------------------------

Will be fixed later: the workaround is to switch to the graphical tab before saving to have the proper image generation

> image generation fails
> ----------------------
>
>                 Key: GPD-336
>                 URL: https://jira.jboss.org/jira/browse/GPD-336
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> image generation seems to work for org.jbpm.examples.async.activity
> but it seems to fail for org.jbpm.examples.async.fork.  in that case I get an image with only a diagonal line.
> koen, do you get the same with that example ?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 11:17:52 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:17:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-229) Write up the initial
 test scenario's to test the GPD (automated or manual)
In-Reply-To: <9329862.1216376692216.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1903604632.1246893472923.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-229.
---------------------------

    Resolution: Done


> Write up the initial test scenario's to test the GPD (automated or manual)
> --------------------------------------------------------------------------
>
>                 Key: GPD-229
>                 URL: https://jira.jboss.org/jira/browse/GPD-229
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 11:17:52 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:17:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-336) image generation fails
In-Reply-To: <18908917.1242894356480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1861503600.1246893472244.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-336:
--------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)
         Priority: Minor  (was: Major)


> image generation fails
> ----------------------
>
>                 Key: GPD-336
>                 URL: https://jira.jboss.org/jira/browse/GPD-336
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> image generation seems to work for org.jbpm.examples.async.activity
> but it seems to fail for org.jbpm.examples.async.fork.  in that case I get an image with only a diagonal line.
> koen, do you get the same with that example ?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 11:21:03 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-334) update jbpm roadmap
 with gpd features
In-Reply-To: <10900511.1242229666628.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1964583391.1246893663836.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-334.
---------------------------

    Resolution: Out of Date


> update jbpm roadmap with gpd features
> -------------------------------------
>
>                 Key: GPD-334
>                 URL: https://jira.jboss.org/jira/browse/GPD-334
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>
> http://www.jboss.org/community/docs/DOC-13217

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 11:27:52 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 6 Jul 2009 11:27:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1295017179.1246894072528.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475055#action_12475055 ] 

jaikiran pai commented on JBMETA-208:
-------------------------------------

>> 4. If it contains neither a DTD nor a namespace, display a warning that you are entering 'compatibility mode' where you both process the ejb-jar.xml and scan for annotations (at the expense of reduced startup time). The warning should advise the developer 'either add a DTD or a namespace to avoid this warning' 

IMO, it should print out a WARN that will inform the user/dev that the deployment will *not* be scanned for annotations. The developer can then fix it appropriately. This nicely fits in with the requirement that 

1) EJB3 deployment require a namespace 
2) User being notified of an incorrect ejb-jar.xml
3) No additional performance cost.


> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <ejb-jar version="3.0"
>     xmlns="http://java.sun.com/xml/ns/javaee"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 11:32:08 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 6 Jul 2009 11:32:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-531) Build testsuite
 classpaths directly against jars in local maven repository
In-Reply-To: <6026725.1243637396349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <536901684.1246894328153.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBBUILD-531:
-----------------------------------


The JBoss-AS-6.0.x-testSuite-sun16 job,
http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-testSuite-sun16/

is failing with:
BUILD FAILED
/qa/hudson_ws/workspace/JBoss-AS-6.0.x-testSuite-sun16/JBossAS/testsuite/build.xml:1029: The following error occurred while executing this line:
/qa/hudson_ws/workspace/JBoss-AS-6.0.x-testSuite-sun16/JBossAS/testsuite/imports/config/tests-clustering.xml:105: The following error occurred while executing this line:
/qa/hudson_ws/workspace/JBoss-AS-6.0.x-testSuite-sun16/JBossAS/testsuite/imports/config/tests-clustering.xml:240: The following error occurred while executing this line:
/qa/hudson_ws/workspace/JBoss-AS-6.0.x-testSuite-sun16/JBossAS/testsuite/build.xml:395: java.lang.OutOfMemoryError: PermGen space

This appears to be a OOM with maven.  The build is run with:
MAVEN_OPTS="-Xmx1024m -Xms512m -XX:PermSize=256m -XX:MaxPermSize=768m"

I recently made a change to testsuite/imports/config/tests-clustering.xml to add init to the tests-clustering-unit target 
http://fisheye.jboss.org/changelog/JBossAS/?cs=90757
to resolve this:
/qa/hudson_ws/workspace/JBoss-AS-6.0.x-testSuite-sun16/JBossAS/testsuite/imports/config/tests-clustering.xml:392: Reference apache-httpclient:commons-httpclient:jar not found.



> Build testsuite classpaths directly against jars in local maven repository
> --------------------------------------------------------------------------
>
>                 Key: JBBUILD-531
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-531
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the testsuite uses the jars in thirdparty.  Instead the paths in the testsuite should directly reference jars in the local maven repository directory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 11:32:08 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:32:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-331) Support HQL
 attributes and elements
In-Reply-To: <143992.1241701546509.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1275789815.1246894328417.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-331.
---------------------------

    Resolution: Done


> Support HQL attributes and elements
> -----------------------------------
>
>                 Key: GPD-331
>                 URL: https://jira.jboss.org/jira/browse/GPD-331
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> attributes: var, unique
> elements: query, parameter

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 11:32:08 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 6 Jul 2009 11:32:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMETA-208) Prescence of an
 ejb-jar.xml
 without a namespace stops annotation-based metadata processing
In-Reply-To: <14910045.1245196985920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1761761605.1246894328279.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMETA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475058#action_12475058 ] 

Alexey Loubyansky commented on JBMETA-208:
------------------------------------------

You'd have to do it for every EJB2 deployment. In that case it's better just to log the EJB version of the deployment.

> Prescence of an ejb-jar.xml without a namespace stops annotation-based metadata processing
> ------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-208
>                 URL: https://jira.jboss.org/jira/browse/JBMETA-208
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.0.1.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Alexey Loubyansky
>
> The presence of a META-INF/ejb-jar.xml file that is not properly namespaced, for example...
> <ejb-jar>
> </ejb-jar>
> ...instead of...
> <ejb-jar version="3.0"
>     xmlns="http://java.sun.com/xml/ns/javaee"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
> </ejb-jar>
> ...stops ALL of the annotation-based metadata processing. Every session bean in the JAR reports with the JBMETA-4 warning, and therefore none of them get registered with JNDI. This is much worse than simply ignoring the ejb-jar.xml altogether, as is arguably acceptable as it isn't namespaced.
> An un-namespaced ejb-jar.xml is not uncommon. Many examples, including this one from the JBoss documentation...
> http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/partial_deployment_descriptors.html
> ...leave off the namespace, so for JBoss to fail without warning seems a little harsh. Leaving off the namespace worked fine in JBoss 4.2.3.GA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 11:33:51 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:33:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-341) renaming swimlane
 should make editor dirty
In-Reply-To: <31349923.1243352997231.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1706931486.1246894431910.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-341.
---------------------------

    Resolution: Done


> renaming swimlane should make editor dirty
> ------------------------------------------
>
>                 Key: GPD-341
>                 URL: https://jira.jboss.org/jira/browse/GPD-341
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 11:39:53 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:39:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-306) Self Referencing
	Connections
In-Reply-To: <6129383.1237558244506.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <643097081.1246894793293.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-306:
--------------------------

      Component/s: jpdl
    Fix Version/s: jBPM jPDL Designer 4.0.x
                       (was: jBPM jPDL Designer 4.0.0.GA)
         Priority: Minor  (was: Major)


> Self Referencing Connections
> ----------------------------
>
>                 Key: GPD-306
>                 URL: https://jira.jboss.org/jira/browse/GPD-306
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> There should be a convenient way to create connections that reference the same node as source and target

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 11:39:53 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 6 Jul 2009 11:39:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-306) Self Referencing
	Connections
In-Reply-To: <6129383.1237558244506.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <190140969.1246894793236.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/GPD-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475063#action_12475063 ] 

Koen Aers commented on GPD-306:
-------------------------------

 Postponed until a later version: workaround is to add the transition manually in the xml view

> Self Referencing Connections
> ----------------------------
>
>                 Key: GPD-306
>                 URL: https://jira.jboss.org/jira/browse/GPD-306
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> There should be a convenient way to create connections that reference the same node as source and target

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 12:10:51 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Mon, 6 Jul 2009 12:10:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7078) Create
 SSLSocketFactory that uses a JaasSecurityDomain
In-Reply-To: <565179297.1246891551731.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1687217202.1246896651420.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcus Moyses resolved JBAS-7078.
---------------------------------

    Resolution: Done


org.jboss.security.ssl.JaasSecurityDomainSocketFactory was created for this purpose.
By default it expects the security domain name in the org.jboss.security.ssl.domain.name system property. 

> Create SSLSocketFactory that uses a JaasSecurityDomain
> ------------------------------------------------------
>
>                 Key: JBAS-7078
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7078
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Marcus Moyses
>            Assignee: Marcus Moyses
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> We need a SSLSocketFactory with a default constructor and a static getDefault method that sets up SSL using a JaasSecurityDomain mbean so it can be used for LDAPS, Remoting, etc.
> The name of the security domain must be set as a system property.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 12:22:51 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Mon, 6 Jul 2009 12:22:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-533) Update jboss
 parent pom and
 wiki to use webdav for deploying to releases repository
Message-ID: <614718933.1246897371972.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Update jboss parent pom and wiki to use webdav for deploying to releases repository
-----------------------------------------------------------------------------------

                 Key: JBBUILD-533
                 URL: https://jira.jboss.org/jira/browse/JBBUILD-533
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven Builds
            Reporter: Paul Gier
             Fix For: Maven Build - Maint 2009


The webdav URL (dav:https://svn.jboss.org/repos/repository.jboss.org/maven2) should be used when deploying to the jboss maven repository instead of the current method of checkout out the repository first.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 13:40:51 2009
From: jira-events at lists.jboss.org (Naresh Bhatia (JIRA))
Date: Mon, 6 Jul 2009 13:40:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1677) "Connection
 failure has been detected" message
Message-ID: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

"Connection failure has been detected" message
----------------------------------------------

                 Key: JBMESSAGING-1677
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0.beta3
         Environment: Windows XP SP2
            Reporter: Naresh Bhatia
            Assignee: Tim Fox


I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.

Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 

22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
om server:3
...
23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
ient. It is likely a client has exited or crashed without closing its connection, or the network bet
ween the server and client has failed. The connection will now be closed.:3
23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
8-11de-9025-0016d433fcb5
23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 13:42:51 2009
From: jira-events at lists.jboss.org (Naresh Bhatia (JIRA))
Date: Mon, 6 Jul 2009 13:42:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1933608586.1246902171467.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Naresh Bhatia updated JBMESSAGING-1677:
---------------------------------------

    Attachment: JmsTest.zip


Attaching file.

> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Tim Fox
>         Attachments: JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 14:00:51 2009
From: jira-events at lists.jboss.org (Bob Shanahan (JIRA))
Date: Mon, 6 Jul 2009 14:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-5922) Allow shutdown.sh
 to still work if it passed a http(s) jndi url
In-Reply-To: <11373674.1220431139264.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <202009484.1246903251829.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475085#action_12475085 ] 

Bob Shanahan commented on JBAS-5922:
------------------------------------

The JNDI url ends with JNDIFactory, not JNDIProxy, hence the shutdown command is

shutdown.sh -s http://localhost:8080/invoker/JNDIFactory -S

If using the 'nix service script, change the stop command to the following:

JBOSS_CMD_STOP=${JBOSS_CMD_STOP:-"java -classpath $JBOSSCP org.jboss.Shutdown -s http://localhost:8080/invoker/JNDIFactory



> Allow shutdown.sh to still work if it passed a http(s) jndi url
> ---------------------------------------------------------------
>
>                 Key: JBAS-5922
>                 URL: https://jira.jboss.org/jira/browse/JBAS-5922
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>            Reporter: Adrian Brock
>            Assignee: Adrian Brock
>             Fix For: JBossAS-5.0.0.CR2
>
>
> If shutdown.sh|.bat is passed a http jndi url, e.g.
> http://localhost:8080/invoker/JNDIProxy
> then it should still be able to shutdown the server
> as long as it can obtain an MBeanServerConnection usable remotely.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 14:00:52 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 6 Jul 2009 14:00:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7074) some jars required
 by remote Profile Service clients are not included in client/ or
 client/jboss-clientall.jar
In-Reply-To: <631441563.1246562451433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <905805639.1246903252300.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475086#action_12475086 ] 

Ian Springer commented on JBAS-7074:
------------------------------------

Also missing from both client/ and jbossall-client.jar's MANIFEST.MF:

    lib/jboss-dependency.jar

Here's a stack trace from an exception thrown by a remote EJB PS client that does not have jboss-dependency.jar in its classpath:

java.lang.NoClassDefFoundError: org/jboss/dependency/spi/ControllerState
        at org.jboss.profileservice.spi.types.ControllerStateMetaType.<init>(ControllerStateMetaType.java:53)
        at org.jboss.profileservice.spi.types.ControllerStateMetaType.<clinit>(ControllerStateMetaType.java:49)
        at sun.misc.Unsafe.ensureClassInitialized(Native Method)
        at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
        at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
        at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
        at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
        at java.lang.reflect.Field.getLong(Field.java:528)
        at java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1614)
        at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52)
        at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:425)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:413)
        at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310)
        at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:547)
        at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583)
        at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.managed.plugins.DefaultFieldsImpl.readObject(DefaultFieldsImpl.java:381)
        at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.managed.plugins.ManagedPropertyImpl.readVersion1(ManagedPropertyImpl.java:663)
        at org.jboss.managed.plugins.ManagedPropertyImpl.readObject(ManagedPropertyImpl.java:633)
        at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at java.util.HashMap.readObject(HashMap.java:1030)
        at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.skipCustomData(ObjectInputStream.java:1912)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1874)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
        at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
        at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
        at $Proxy7.invoke(Unknown Source)
        at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
        at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
        at $Proxy4.getComponentsForType(Unknown Source)
        at test.Worker.run(Worker.java:44)
        at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.ClassNotFoundException: org.jboss.dependency.spi.ControllerState
        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:307)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
        ... 96 more


> some jars required by remote Profile Service clients are not included in client/ or client/jboss-clientall.jar
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7074
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7074
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The classes from the following jar are missing from jboss-clientall.jar and the jar itself is missing from client/:
>    common/lib/jboss-security-aspects.jar
> Its corresponding Maven artifact is org.jboss.aspects:jboss-security-aspects.
> If I find any others, I will update this JIRA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 14:02:51 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 6 Jul 2009 14:02:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7074) some jars required
 by remote Profile Service clients are not included in client/ or
 client/jbossall-client.jar's Manifest classpath
In-Reply-To: <631441563.1246562451433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <815380177.1246903371467.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7074:
-------------------------------

        Summary: some jars required by remote Profile Service clients are not included in client/ or client/jbossall-client.jar's Manifest classpath  (was: some jars required by remote Profile Service clients are not included in client/ or client/jboss-clientall.jar)
    Description: 
The following jar is missing from client/jbossall-client.jar's Manifest classpath and from client/:

   common/lib/jboss-security-aspects.jar

Its corresponding Maven artifact is org.jboss.aspects:jboss-security-aspects.

If I find any others, I will update this JIRA.


  was:
The classes from the following jar are missing from jboss-clientall.jar and the jar itself is missing from client/:

   common/lib/jboss-security-aspects.jar

Its corresponding Maven artifact is org.jboss.aspects:jboss-security-aspects.

If I find any others, I will update this JIRA.




> some jars required by remote Profile Service clients are not included in client/ or client/jbossall-client.jar's Manifest classpath
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7074
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7074
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The following jar is missing from client/jbossall-client.jar's Manifest classpath and from client/:
>    common/lib/jboss-security-aspects.jar
> Its corresponding Maven artifact is org.jboss.aspects:jboss-security-aspects.
> If I find any others, I will update this JIRA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 14:06:02 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 6 Jul 2009 14:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <432590158.1246903562960.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475087#action_12475087 ] 

Clebert Suconic commented on JBMESSAGING-1677:
----------------------------------------------



Can you provide some guide on how to build id please?


I have tried the regular paths such as mvn install:install, and it didn't work.

It was complaining about missing samples.jmstestLjmstest-listener:ejb:1.0


Thanks

> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Tim Fox
>         Attachments: JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 14:11:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 6 Jul 2009 14:11:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-106) SJC: Add support for
 property maps
Message-ID: <1148079522.1246903911428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC: Add support for property maps
----------------------------------

                 Key: JBJCA-106
                 URL: https://jira.jboss.org/jira/browse/JBJCA-106
             Project: JBoss JCA
          Issue Type: Task
          Components: Core
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Add support for property maps, so they can be passed in the configuration.

The remotable naming server is an example of an use-case.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 14:17:05 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 6 Jul 2009 14:17:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-107) SJC: Add support for
 a default value in system properties
Message-ID: <803321689.1246904225294.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC: Add support for a default value in system properties
---------------------------------------------------------

                 Key: JBJCA-107
                 URL: https://jira.jboss.org/jira/browse/JBJCA-107
             Project: JBoss JCA
          Issue Type: Task
          Components: Core
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Add support for a default in system properties like

 ${jboss.bind.address:localhost}


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 14:18:52 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Mon, 6 Jul 2009 14:18:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JGRP-1003) deadlock in TP.send
 - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1004131569.1246904332061.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Victor N reopened JGRP-1003:
----------------------------



Hi Bela,
another day, another bug :)

So... I have configured use_send_queues="true" for TCP. After some time I have got another strange situation - one of my servers was excluded from group and never rejoined. I looked into stack traces - I am sending you "jgroups_s1.txt" file by email, please look.

You will see one thread:

"Connection.Sender [server1:40001 - server2:33324],GateCluster,server1:40001" prio=10 tid=0x08f9d400 nid=0x147e waiting on condition [0x187d6000..0x187d7140]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x830c5d28> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358)
	at org.jgroups.blocks.TCPConnectionMap$TCPConnection$Sender.run(TCPConnectionMap.java:594)
	at java.lang.Thread.run(Thread.java:619)

This means that the thread is waiting until S ender's queue becomes non-empty (LinkedBlockingQueue.java:358):

while (count.get() == 0)
                    notEmpty.await();


But at the same time there are many threads like this (trying to send something to network):

"pool-2-thread-2" prio=10 tid=0x0891a000 nid=0x1f9d waiting on condition [0x20afe000..0x20aff0c0]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x63ac53e8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925)
	at java.util.concurrent.LinkedBlockingQueue.put(LinkedBlockingQueue.java:254)
	at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:429)
	at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)
	at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)
	at org.jgroups.protocols.TCP.send(TCP.java:53)
	at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)
	at org.jgroups.protocols.BasicTCP.sendToAllMembers(BasicTCP.java:126)
	at org.jgroups.protocols.TP.doSend(TP.java:1102)
	at org.jgroups.protocols.TP.access$1600(TP.java:52)
	at org.jgroups.protocols.TP$Bundler.sendBundledMessages(TP.java:1548)
	at org.jgroups.protocols.TP$Bundler.send(TP.java:1484)
	at org.jgroups.protocols.TP$Bundler.access$200(TP.java:1461)
	at org.jgroups.protocols.TP.send(TP.java:1077)
	at org.jgroups.protocols.TP.down(TP.java:907)
	at org.jgroups.protocols.Discovery.down(Discovery.java:363)
	at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)
	at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)
	at org.jgroups.protocols.FD.down(FD.java:327)
	at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)
	at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)
	at org.jgroups.protocols.pbcast.NAKACK.send(NAKACK.java:771)
	at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:572)
	at org.jgroups.protocols.UNICAST.down(UNICAST.java:468)
	at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:322)
	at org.jgroups.protocols.VIEW_SYNC.down(VIEW_SYNC.java:196)
	at org.jgroups.protocols.pbcast.GMS.down(GMS.java:939)
	at org.jgroups.protocols.FC.handleDownMessage(FC.java:617)
	at org.jgroups.protocols.FC.down(FC.java:434)
	at org.jgroups.protocols.FRAG2.down(FRAG2.java:158)
	at org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER.down(STREAMING_STATE_TRANSFER.java:275)
	at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:838)
	at org.jgroups.JChannel.down(JChannel.java:1504)
	at org.jgroups.JChannel.send(JChannel.java:670)
	at org.jgroups.JChannel.send(JChannel.java:686)
	at mytest.cluster.JGroupsClusterManagerImpl.doSendMessageToAllGates(JGroupsClusterManagerImpl.java:93)
	at mytest.cluster.JGroupsClusterManagerImpl.access$000(JGroupsClusterManagerImpl.java:24)
	at mytest.cluster.JGroupsClusterManagerImpl$1.run(JGroupsClusterManagerImpl.java:81)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)

This means that this 2nd thread is waiting until Sender's queue becomes non-full (LinkedBlockingQueue.java:254):

while (count.get() == capacity)
                    notFull.await();


How can this be at the same time - the same queue is empty and full?
Maybe there are 2 different instances of sender queue and 2 different senders? Is a new sender created in some situations (shunning, reconnect, etc.)?

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 14:20:51 2009
From: jira-events at lists.jboss.org (Naresh Bhatia (JIRA))
Date: Mon, 6 Jul 2009 14:20:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <796520070.1246904451820.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475090#action_12475090 ] 

Naresh Bhatia commented on JBMESSAGING-1677:
--------------------------------------------

I suspect that you are running mvn install in the jmstest-ear directory. Can you confirm if the same issue exists if you run mvn install in the parent directory (JmsTest)? That will make sure that all the dependencies are built before the EAR is built.

> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Tim Fox
>         Attachments: JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 14:24:51 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Mon, 6 Jul 2009 14:24:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <573757652.1246904691827.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475091#action_12475091 ] 

Victor N commented on JGRP-1003:
--------------------------------

Definitely, I am going to test with TCP_NIO ! I hope it does not need send queues and does not block in "send" call.

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 14:28:52 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 6 Jul 2009 14:28:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-108) SJC: Add support for
 <constructor>
Message-ID: <962038176.1246904932262.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC: Add support for <constructor>
----------------------------------

                 Key: JBJCA-108
                 URL: https://jira.jboss.org/jira/browse/JBJCA-108
             Project: JBoss JCA
          Issue Type: Task
          Components: Core
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Add support for <constructor> constructs for beans. 

An example

    <bean name="LookupPool">
        <constructor factoryMethod="newFixedThreadPool"  factoryClass="java.util.concurrent.Executors">
            <parameter>2</parameter>
        </constructor>
    </bean>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 14:28:52 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 6 Jul 2009 14:28:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1599339048.1246904932654.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475093#action_12475093 ] 

Clebert Suconic commented on JBMESSAGING-1677:
----------------------------------------------

I had done that before.

anyway.. it worked when I removed my $HOME/.m2/repository



> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Tim Fox
>         Attachments: JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 14:39:04 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Mon, 6 Jul 2009 14:39:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7078) Create
 SSLSocketFactory that uses a JaasSecurityDomain
In-Reply-To: <565179297.1246891551731.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <334551484.1246905544032.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475098#action_12475098 ] 

Marcus Moyses commented on JBAS-7078:
-------------------------------------

More information:
http://www.jboss.org/community/wiki/JaasSecurityDomainSocketFactory

> Create SSLSocketFactory that uses a JaasSecurityDomain
> ------------------------------------------------------
>
>                 Key: JBAS-7078
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7078
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Marcus Moyses
>            Assignee: Marcus Moyses
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> We need a SSLSocketFactory with a default constructor and a static getDefault method that sets up SSL using a JaasSecurityDomain mbean so it can be used for LDAPS, Remoting, etc.
> The name of the security domain must be set as a system property.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 14:44:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 6 Jul 2009 14:44:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-109) Cobertura 1.9.2
Message-ID: <2038758232.1246905891403.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Cobertura 1.9.2
---------------

                 Key: JBJCA-109
                 URL: https://jira.jboss.org/jira/browse/JBJCA-109
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 14:52:51 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 6 Jul 2009 14:52:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-131) OpenID Integration
Message-ID: <1207990758.1246906371307.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

OpenID Integration
------------------

                 Key: JBID-131
                 URL: https://jira.jboss.org/jira/browse/JBID-131
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1


Integrate Openid4Java which is ASL 2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 15:18:51 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Mon, 6 Jul 2009 15:18:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-422) Allow
 LdapExtLoginModule to
 read the bind credential with an external command
Message-ID: <340822324.1246907931488.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Allow LdapExtLoginModule to read the bind credential with an external command
-----------------------------------------------------------------------------

                 Key: SECURITY-422
                 URL: https://jira.jboss.org/jira/browse/SECURITY-422
             Project: JBoss Security and Identity Management
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: JBossSecurity_2.0.3.SP2
            Reporter: Marcus Moyses
            Assignee: Marcus Moyses
             Fix For: JBossSecurity_2.0.3.SP2


The LdapExtLoginModule bust be able to read the bind credential password with an external command.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 15:24:51 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Mon, 6 Jul 2009 15:24:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (SECURITY-422) Allow
 LdapExtLoginModule to
 read the bind credential with an external command
In-Reply-To: <340822324.1246907931488.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <582599647.1246908291420.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcus Moyses resolved SECURITY-422.
------------------------------------

    Resolution: Done


Feature implemented. An example would be:

<module-option name="bindCredential">{EXT}cat mypassword</module-option>

> Allow LdapExtLoginModule to read the bind credential with an external command
> -----------------------------------------------------------------------------
>
>                 Key: SECURITY-422
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-422
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: JBossSecurity_2.0.3.SP2
>            Reporter: Marcus Moyses
>            Assignee: Marcus Moyses
>             Fix For: JBossSecurity_2.0.3.SP2
>
>
> The LdapExtLoginModule bust be able to read the bind credential password with an external command.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 15:41:51 2009
From: jira-events at lists.jboss.org (Rostyslav Smirnov (JIRA))
Date: Mon, 6 Jul 2009 15:41:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7079) Can't redirect root
 requests without ROOT.war
Message-ID: <1964202660.1246909311435.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Can't redirect root requests without ROOT.war
---------------------------------------------

                 Key: JBAS-7079
                 URL: https://jira.jboss.org/jira/browse/JBAS-7079
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Tomcat) service
    Affects Versions: JBossAS-5.1.0.GA
         Environment: Windows XP, JDK 1.6.0_14
            Reporter: Rostyslav Smirnov
            Assignee: Remy Maucherat


When ROOT.war is removed, root URL request always returns 404, ignoring URL rewrite rules.

Steps to reproduce:

1) Set up a single URL rewriting rule for jboss.web engine that redirects root requests:

RewriteRule ^/$ /admin-console/ [R]

At this point everything works and http://localhost:8080/ becomes http://localhost:8080/admin-console/

2) As the ROOT.war is now inaccessible, remove or rename it. Now http://localhost:8080/ just returns 404, ignoring the rule.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 16:14:51 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Mon, 6 Jul 2009 16:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7080) Add options to set
 providers and algorithms in the JaasSecurityDomain
Message-ID: <1841490058.1246911291396.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add options to set providers and algorithms in the JaasSecurityDomain
---------------------------------------------------------------------

                 Key: JBAS-7080
                 URL: https://jira.jboss.org/jira/browse/JBAS-7080
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Marcus Moyses
            Assignee: Marcus Moyses
             Fix For: JBossAS-5.2.0.Beta1


Need to add options to set the provider for the KeyStore, TrustStore, KeyManagerFactory and TrustManagerFactory.
Need to add options to set the algorithm for the KeyManagerFactory and TrustManagerFactory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 16:16:55 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 6 Jul 2009 16:16:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1354336854.1246911415278.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBXB-206:
---------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242058


> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>            Assignee: Alexey Loubyansky
>         Attachments: jboss-profiler.properties, jbossxb.zip, server.log.gz
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 16:35:52 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Mon, 6 Jul 2009 16:35:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7080) Add options to set
 providers and algorithms in the JaasSecurityDomain
In-Reply-To: <1841490058.1246911291396.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <934579436.1246912552016.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcus Moyses resolved JBAS-7080.
---------------------------------

    Resolution: Done


The following options are now available:
KeyStoreProvider
KeyManagerFactoryProvider
TrustStoreProvider
TrustManagerFactoryProvider
KeyManagerFactoryAlgorithm
TrustManagerFactoryAlgorithm 

> Add options to set providers and algorithms in the JaasSecurityDomain
> ---------------------------------------------------------------------
>
>                 Key: JBAS-7080
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7080
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Marcus Moyses
>            Assignee: Marcus Moyses
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Need to add options to set the provider for the KeyStore, TrustStore, KeyManagerFactory and TrustManagerFactory.
> Need to add options to set the algorithm for the KeyManagerFactory and TrustManagerFactory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 16:37:52 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 6 Jul 2009 16:37:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7081)
 ConcurrentModificationException
 when invoking 'stop' managed operation on Queue managed component
Message-ID: <1715358388.1246912672146.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

ConcurrentModificationException when invoking 'stop' managed operation on Queue managed component
-------------------------------------------------------------------------------------------------

                 Key: JBAS-7081
                 URL: https://jira.jboss.org/jira/browse/JBAS-7081
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Ian Springer
            Assignee: Scott M Stark
             Fix For: JBossAS-5.2.0.Beta1


Here's the stack trace:

Exception when invoking stop(): java.lang.reflect.UndeclaredThrowableException: Failed to invoke method 'stop' on component 'jboss.messaging.destination:name=ex
,service=Queue' with parameters [].
Exception in thread "Thread-28" java.lang.RuntimeException: javax.ejb.EJBException: java.util.ConcurrentModificationException
        at test.Worker.run(Worker.java:102)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.ejb.EJBException: java.util.ConcurrentModificationException
        at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:77)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
        at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
        at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
        at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
        at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
Caused by: java.util.ConcurrentModificationException
        at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
        at java.util.HashMap$EntryIterator.next(HashMap.java:834)
        at java.util.HashMap$EntryIterator.next(HashMap.java:832)
        at org.jboss.util.TimedCachePolicy.getValidKeys(TimedCachePolicy.java:364)
        at org.jboss.virtual.plugins.cache.IterableTimedVFSCache.findContext(IterableTimedVFSCache.java:65)
        at org.jboss.virtual.plugins.cache.CombinedVFSCache.findContext(CombinedVFSCache.java:116)
        at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:91)
        at org.jboss.virtual.VFS.getRoot(VFS.java:200)
        at org.jboss.profileservice.management.templates.JmsDestinationTemplate.applyTemplate(JmsDestinationTemplate.java:115)
        at org.jboss.profileservice.management.AbstractTemplateCreator.applyTemplate(AbstractTemplateCreator.java:99)
        at org.jboss.profileservice.management.ManagementViewImpl.applyTemplate(ManagementViewImpl.java:1362)
        at sun.reflect.GeneratedMethodAccessor449.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$3.applyTemplate(AOPProxy$3.java)
        at org.jboss.profileservice.ejb.SecureManagementView.applyTemplate(SecureManagementView.java:77)
        at sun.reflect.GeneratedMethodAccessor446.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
        at org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
        at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
        at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
        at sun.reflect.GeneratedMethodAccessor386.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
        at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_29585222.invoke(InvocationContextInterceptor_z_fillMet
hod_29585222.java)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
        at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_29585222.invoke(InvocationContextInterceptor_z_setup_295852
22.java)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
        at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
        at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
        at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
        at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$3.applyTemplate(AOPProxy$3.java)
        at org.jboss.profileservice.ejb.SecureManagementView.applyTemplate(SecureManagementView.java:77)
        at sun.reflect.GeneratedMethodAccessor446.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
        at org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
        at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
        at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
        at sun.reflect.GeneratedMethodAccessor386.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
        at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_29585222.invoke(InvocationContextInterceptor_z_fillMet
hod_29585222.java)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
        at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_29585222.invoke(InvocationContextInterceptor_z_setup_295852
22.java)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
        at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
        at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
        at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
        at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
        at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
        at $Proxy7.invoke(Unknown Source)
        at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
        at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
        at $Proxy4.applyTemplate(Unknown Source)
        at test.Worker.run(Worker.java:93)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
        at $Proxy7.invoke(Unknown Source)
        at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
        at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
        at $Proxy4.applyTemplate(Unknown Source)
        at test.Worker.run(Worker.java:93)
        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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 16:57:51 2009
From: jira-events at lists.jboss.org (denny Valliant (JIRA))
Date: Mon, 6 Jul 2009 16:57:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3248) JBoss
 xercesImpl.jar conflicts with xerces.jar within Ears/wars
Message-ID: <138358849.1246913871546.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475124#action_12475124 ] 

denny Valliant commented on JBAS-3248:
--------------------------------------

You can just delete the xercesImpl jar in the jasperserver/WEB-INF/lib folder and it will start fine.  Haven't done extensive testing with XML stuff to make sure there isn't something broken deep inside, but everything seems to work just dandy.

> JBoss xercesImpl.jar conflicts with xerces.jar within Ears/wars
> ---------------------------------------------------------------
>
>                 Key: JBAS-3248
>                 URL: https://jira.jboss.org/jira/browse/JBAS-3248
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading, Clustering
>    Affects Versions: JBossAS-4.0.3 SP1
>         Environment: Red Hat Enterprise Linux ES release 4;
> java version 1.5.0_06;
> JBoss in cluster mode
>            Reporter: Alan
>            Assignee: Scott M Stark
>
> I have an application (.war file) that uses a lib called xerces.jar located at .war /WEB-INF/lib directory. I run JBoss in cluster mode. So, after deploy, when I run my application, I got an exception with the xml libs. I guess it's a classloader problem. MY application tries to use the JBoss xml classes intead of it's own. I discovered the problem was with the xerces.jar and xercesImpl.jar because I deleted the line below from the <JBOSS_HOME>/bin/run.sh:
> -Djava.endorsed.dirs=...
> I searched for a solution and discovered jdk versions before 1.5 have a bug with xml, so I tried the solution above and all worked fine. Now my application use it's own xerces instead of JBoss xerces.
> I think my solution is a workaround. I would like to know if there is a better way to solve this problem. Is there ?
> The exception is below.
> Than you.
> Alan
> The exception:
> java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.apache.struts.actions.DispatchAction.perform(DispatchAction.java :236)
>         at org.apache.struts.action.ActionServlet.processActionPerform(ActionServlet.java:1787)
>         at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1586)
>         at org.apache.struts.action.ActionServlet.doPost (ActionServlet.java:510)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:252)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java :81)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>         at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke (CustomPrincipalValve.java:39)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
>         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java :407)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>         at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:105)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
>         at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket (PoolTcpEndpoint.java:527)
>         at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.VerifyError: (class: org/apache/soap/util/xml/XercesParserLiaison, method: read signature: (Ljava/lang/String;Ljava/io/Reader;)Lorg/w3c/dom/Document;) Incompatible object argument 
>  for function call
>         at org.apache.soap.rpc.Call.<init>(Call.java)
>         at org.apache.soap.rpc.Call.<init>(Call.java)
>         at com.attachmate.mcs.agent.impl.SOAPPackager.a(SOAPPackager.java )
> ...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 20:51:51 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 6 Jul 2009 20:51:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <298403386.1246927911482.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-7032:
---------------------------------


John, I am able to reproduce the issue.  Let me continue to investigate the root cause.

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul  6 21:38:51 2009
From: jira-events at lists.jboss.org (John Ament (JIRA))
Date: Mon, 6 Jul 2009 21:38:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <251433786.1246930731498.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475142#action_12475142 ] 

John Ament commented on JBAS-7032:
----------------------------------

It's funny that this got brought back up, I was about to update this as well.  After some playing with it, if I configure the server to enter a clustered environment, I can get it (admin-console.war) to deploy correctly but attempting to access it results in a no active conversation exception.  I've only been able to reproduce this with a webbeans deployment, I'm not sure about you.  From what I can tell, the fact that it's deploying is apparently a bug w/ the current webbeans ri which doesn't seem to work correctly in a clustered environment.  The no active conversation is a result of the webbeans deployer and filter taking higher precedence over the seam deployment (I verified by looking at the stack trace and seeing that the seam request was running through the webbeans filter, rather than the seam filter).  If you believe it's relevant, I'll post that stacktrace tomorrow.

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 02:01:51 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 7 Jul 2009 02:01:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1003) deadlock in TP.send
 - socket
 write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2002041713.1246946511803.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1003:
---------------------------

    Attachment: stacktrace.txt


> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>         Attachments: stacktrace.txt
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 04:06:52 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Tue, 7 Jul 2009 04:06:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-105) SJC/RAdeployer: Add
 support for DTDs
In-Reply-To: <1880250736.1246887652072.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2011844206.1246954012093.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved JBJCA-105.
------------------------------

    Resolution: Done


> SJC/RAdeployer: Add support for DTDs
> ------------------------------------
>
>                 Key: JBJCA-105
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-105
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>   Original Estimate: 0 minutes
>  Remaining Estimate: 0 minutes
>
> Add dtd deployment into sjc deployer
> create this task for tacking this function. code commit r90827 should belong this task

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 04:06:51 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Tue, 7 Jul 2009 04:06:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-105) SJC/RAdeployer: Add
 support for DTDs
In-Reply-To: <1880250736.1246887652072.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <554233812.1246954011961.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang updated JBJCA-105:
-----------------------------

     Original Estimate: 0 minutes
    Remaining Estimate: 0 minutes
              Due Date: 07/Jul/09


> SJC/RAdeployer: Add support for DTDs
> ------------------------------------
>
>                 Key: JBJCA-105
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-105
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>   Original Estimate: 0 minutes
>  Remaining Estimate: 0 minutes
>
> Add dtd deployment into sjc deployer
> create this task for tacking this function. code commit r90827 should belong this task

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 07:39:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 07:39:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBRULES-2157) Outline problems
	in DRL editor
In-Reply-To: <930975006.1246966791446.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1589864955.1246966791564.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Neil Wallace deleted JBRULES-2157:
----------------------------------


> Outline problems in DRL editor
> ------------------------------
>
>                 Key: JBRULES-2157
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2157
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Neil Wallace
>            Assignee: Kris Verlaenen
>            Priority: Minor
>
> Two (possibly related) problems with the outline view in the DRL editor:
> *) Rules that are commented out via a multi-line comment (/* ... */) still appear in the outline.
> *) Clicking on the name of a rule highlights some text near that rule.  I assume it's supposed to highight the title of the rule, but it misses.  Same thing affects the imports.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 07:39:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 07:39:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2157) Outline problems
	in DRL editor
Message-ID: <930975006.1246966791446.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Outline problems in DRL editor
------------------------------

                 Key: JBRULES-2157
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2157
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse
    Affects Versions: 3.0.4
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
            Priority: Minor
             Fix For: 5.0.1.FINAL


Two (possibly related) problems with the outline view in the DRL editor:

*) Rules that are commented out via a multi-line comment (/* ... */) still appear in the outline.

*) Clicking on the name of a rule highlights some text near that rule.  I assume it's supposed to highight the title of the rule, but it misses.  Same thing affects the imports.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 07:42:04 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 07:42:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2158) CLONE -Outline
 problems in DRL editor
Message-ID: <1063571693.1246966924703.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Outline problems in DRL editor
-------------------------------------

                 Key: JBRULES-2158
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2158
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse
    Affects Versions: 3.0.4
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
            Priority: Minor
             Fix For: 5.0.1.FINAL


Two (possibly related) problems with the outline view in the DRL editor:

*) Rules that are commented out via a multi-line comment (/* ... */) still appear in the outline.

*) Clicking on the name of a rule highlights some text near that rule.  I assume it's supposed to highight the title of the rule, but it misses.  Same thing affects the imports.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 07:54:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 07:54:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2159) CLONE -DSL Parser
	"eval"
Message-ID: <2073094308.1246967691507.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -DSL Parser "eval"
------------------------

                 Key: JBRULES-2159
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2159
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler-DSL
    Affects Versions: 4.0.1
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
            Priority: Minor
             Fix For: 5.0.1.FINAL


rule "PatternTest"
       when
               $pli:Item( title matches "^Test\s*")
       then
                       #
end

this one compiles but on Runtime it ends in an Exception when title looks for example like this "BlaBla (Test)".

as workaround i thought about using the next part, but

rule "PatternTest"
       when
               $pli:Item( eval(title.matches("^Test\s*")) )
       then
                       #
end

it resolves into, also it shouldn't (because title.matches() is Java Code a shouldn't be parsed by the DSL Parser itself):

SyntaxfehlerRule Compilation error : [Rule name=OnlineStreaming Start,
agendaGroup=MAIN, salience=100, no-loop=true]
com/p7s1/swi/phoenix/n24/Rule_OnlineStreaming_Start_0.java (19:923) :
Invalid escape sequence (valid ones are \b \t \n \f \r \" \' \\ )

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 08:04:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 08:04:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2160) CLONE -Use of
 reserved word as bound variable in a pattern results as NPE
Message-ID: <1001322886.1246968291672.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Use of reserved word as bound variable in a pattern results as NPE
-------------------------------------------------------------------------

                 Key: JBRULES-2160
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2160
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 4.0.2
         Environment: Eclipse 3.2, Windows XP
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


example:

rule "This generates an NPE"
	when
		result : ReservedWordNPEFact(data < 15)
	then
		result.setData(new Integer(1));	 
end

At least in the eclipse IDE, this generates an NPE.  Change result to something like:


rule "This generates an NPE"
	when
		f: ReservedWordNPEFact(data < 15)
	then
		f.setData(new Integer(1));	 
end

and it goes away.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 08:15:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 08:15:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2161) CLONE -Prefix
 'and' and infix 'and' not interchangeable
Message-ID: <523039314.1246968951585.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Prefix 'and' and infix 'and' not interchangeable
-------------------------------------------------------

                 Key: JBRULES-2161
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2161
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 4.0.2
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


The documentation on the 'and' Conditional Element seems to imply that these constructs are equivalent:

		$p1:Entity($code1:code)
		not (and
			$p2:Entity(code == $code1)
			 eval(MyStaticClass.match($p1, $p2))
		)

		$p1:Entity($code1:code)
		not (
			$p2:Entity(code == $code1)
			and eval(MyStaticClass.match($p1, $p2))
		)

Actually, the first version crashes with this message:

unknown:93:7 Unexpected token 'and'[96,2]: unknown:96:2 mismatched token: [@792,3685:3685=')',<12>,96:2]; expecting type THEN

I'm on drools 4.0.2 and mvel14-1.2.8.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 08:27:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 08:27:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2162) CLONE -Issue in
 Drools 4.0.7 when run in Multithreaded environment
Message-ID: <1624228605.1246969671438.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Issue in Drools 4.0.7 when run in Multithreaded environment
------------------------------------------------------------------

                 Key: JBRULES-2162
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2162
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 4.0.7
         Environment: OS AIX 1.5
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


Hi 

We have a batch program(Informatica mapping) which uses Jars taken from an application which uses JBoss Drools 4.0.7 and MVEL 1.3.7. The informatica Integration service runs in AIX Machine with JRE Version 1.5. The batch program process millions of records which in turn calls the Drools API. To improve the performance, we tried running our informatica process in a multi threaded environment(4 threads). While running we got the following exception for every record that we process(across all the threads).



: Exception executing predicate eval( $terDate.before(ExtDateTimeUtils.getDate("01/01/1900")) )
	at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:216)
	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:318)
	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:145)
	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:318)
	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:162)
	at org.drools.reteoo.Rete.assertObject(Rete.java:175)
	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:192)
	at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:71)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:911)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:883)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:684)
	at org.drools.reteoo.ReteooStatelessSession.execute(ReteooStatelessSession.java:160)
	at com.wellpoint.eps.epds.business.framework.rules.jbrules.JBRulesExecutor.fireAllRules(JBRulesExecutor.java:85)
	at com.wellpoint.eps.epds.business.framework.validation.BaseHandlerImpl.validateInternal(BaseHandlerImpl.java:141)
	at com.wellpoint.eps.epds.business.framework.validation.BaseHandlerImpl.validateInternal(BaseHandlerImpl.java:75)
	at com.wellpoint.eps.epds.business.framework.validation.AbstractBusinessRuleHandler.validate(AbstractBusinessRuleHandler.java:43)
	at com.wellpoint.eps.epds.business.application.validation.ProviderContractBusinessRuleHandler.validate(ProviderContractBusinessRuleHandler.java:43)
	at com.wellpoint.eps.epds.business.framework.service.DefaultRuleValidationServiceImpl.applyBusinessRules(DefaultRuleValidationServiceImpl.java:284)
	at com.eps.epds.api.validation.ValidationServiceDeligator$DefaultValidationServiceImpl.validate(ValidationServiceDeligator.java:181)
	at com.informatica.powercenter.server.jtx.JTXPartitionDriverImplGen.inputTransaction(JTXPartitionDriverImplGen.java:1414)
Caused by: org.mvel.CompileException: cannot invoke method
	at org.mvel.optimizers.impl.refl.MethodAccessor.getValue(MethodAccessor.java:54)
	at org.mvel.optimizers.impl.refl.VariableAccessor.getValue(VariableAccessor.java:39)
	at org.mvel.ast.VariableDeepPropertyNode.getReducedValueAccelerated(VariableDeepPropertyNode.java:22)
	at org.mvel.ast.PropertyASTNode.getReducedValueAccelerated(PropertyASTNode.java:21)
	at org.mvel.MVELRuntime.execute(MVELRuntime.java:90)
	at org.mvel.CompiledExpression.getValue(CompiledExpression.java:111)
	at org.mvel.MVEL.executeExpression(MVEL.java:235)
	at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:45)
	at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:209)
	... 20 more
Caused by: java.lang.reflect.InvocationTargetException
	at sun.reflect.GeneratedMethodAccessor45.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:615)
	at org.mvel.optimizers.impl.refl.MethodAccessor.getValue(MethodAccessor.java:46)
	... 28 more
Caused by: java.lang.NullPointerException
	at java.util.Date.getMillisOf(Date.java:953)
	at java.util.Date.before(Date.java:912)
	... 32 more
].




Could you please let me know if this is a known issue or is there any workaround for this problem?


Thanks
Sitaraman

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 08:35:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 08:35:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2163) CLONE -Exception
 when compiling a rule with "dialect mvel"
Message-ID: <904746940.1246970151549.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Exception when compiling a rule with "dialect mvel"
----------------------------------------------------------

                 Key: JBRULES-2163
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2163
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 5.0.0.M1
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


The following expression would compile without any problem with "dialect java":

new String[][]{{"2008-04-01", "2008-04-10"}}

But would generate a compiler error - "Unable to build expression...." with "dialect mvel".

Will upload an sample code to demonstrate this bug.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 08:37:51 2009
From: jira-events at lists.jboss.org (anil kumar (JIRA))
Date: Tue, 7 Jul 2009 08:37:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7082) <h:dataTable> with
 multiple column with single row is not working
Message-ID: <395228322.1246970271476.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

<h:dataTable> with multiple column with single row is not working
-----------------------------------------------------------------

                 Key: JBAS-7082
                 URL: https://jira.jboss.org/jira/browse/JBAS-7082
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.1.0.GA
         Environment: windows
            Reporter: anil kumar


  <h:dataTable id="advScreenConfigId" value="#{HeaderBean.records}" var="screenConfig" >  
           <h:column>               
                <h:outputText  value="#{screenConfig.displayTitle}"> </h:outputText> 
            </h:column>              
 </h:dataTable>

this {HeaderBean.records}, will generate some 6 records.These records are displaying one by one , now its showing in 6 rows. I want all these in single row. I tried using facet but didn't work . Please suggest me on this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 08:40:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 08:40:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2164) CLONE
 -Serialization of
 working memories for rulebases with Accumulates are failing
Message-ID: <158778095.1246970451911.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Serialization of working memories for rulebases with Accumulates are failing
-----------------------------------------------------------------------------------

                 Key: JBRULES-2164
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2164
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  5.0.0.M2
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


Serialization of working memories with rules like this are failing:

rule "Test sum" salience 80
    dialect "java"
    when
    	$sum    : Number( doubleValue >= 10 ) 
    	                       from accumulate( Person( $likes : likes ) and Cheese( type == $likes, $price : price  ),
                                                sum( $price ) );
    then
        results.add( $sum );
end  



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 08:49:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 08:49:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2165) CLONE
 -RulebasePartitioningTest  test failure
Message-ID: <479040377.1246970991468.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -RulebasePartitioningTest  test failure
---------------------------------------------

                 Key: JBRULES-2165
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2165
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-guvnor
    Affects Versions:  5.0.0.M2
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


unit test failure when building MR2 source code 
This works if config.setMultithreadEvaluation( true ); line commented out

-------------------------------------------------------------------------------
Test set: org.drools.integrationtests.RulebasePartitioningTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.15 sec <<< FAILURE!
testRulebasePartitions1(org.drools.integrationtests.RulebasePartitioningTest)  Time elapsed: 0.14 sec  <<< FAILURE!
junit.framework.AssertionFailedError: expected:<3> but was:<0>
    at junit.framework.Assert.fail(Assert.java:47)
    at junit.framework.Assert.failNotEquals(Assert.java:282)
    at junit.framework.Assert.assertEquals(Assert.java:64)
    at junit.framework.Assert.assertEquals(Assert.java:201)
    at junit.framework.Assert.assertEquals(Assert.java:207)
    at org.drools.integrationtests.RulebasePartitioningTest.testRulebasePartitions1(RulebasePartitioningTest.java:82)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 08:55:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 08:55:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2166) CLONE -Decimal
 numbers only
 works on locales that uses "." (dot) for decimal separator
Message-ID: <223861723.1246971351555.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Decimal numbers only works on locales that uses "." (dot) for decimal separator
--------------------------------------------------------------------------------------

                 Key: JBRULES-2166
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2166
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 5.0.0.M3
         Environment: Mac OS X 10.5.5 with default locale to Portuguese/Brazil
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
            Priority: Blocker
             Fix For: 5.0.1.FINAL


Test MiscTest.testExtends fails on my development environment. To ensure that it was a Locale problem i seted on top of this test case the US locale (Locale.setDefault(Locale.US);) and then the test worked.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 08:59:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 08:59:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2167) CLONE -Deadlock
 when RuleAgent
 thread refreshes rules while another thread creates a statefulSession
Message-ID: <1093288537.1246971591536.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Deadlock when RuleAgent thread refreshes rules while another thread creates a statefulSession
----------------------------------------------------------------------------------------------------

                 Key: JBRULES-2167
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2167
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 4.0.7
         Environment: Windows XP SP3
Sun JRE 1.5.0_14
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


I believe I have discovered a deadlock that can occur in drools 4.0.7 if the RuleAgent refreshes its associated RuleBase whilst a new stateful session is being created on the RuleBase by another thread. 

The thread dump below shows the deadlock where the two thread "Timer-15" and "DataSource(com.acme.Source)-2" are deadlocked. Thread "Timer-15" is the timer thread created by the RuleAgent rule refresh mechanism to check if the rules files have changed, and to refresh the rules when a change is found. If it finds changes to the rules then it obtains a lock (<0x189a8d88> (a java.util.HashMap)) and proceeds to removes the old version of the changed package from the RuleBase. To do this it needs to obtain another lock (<0x189a2ba0> (a org.drools.reteoo.ReteooRuleBase)) before it can call removeRule.

However, in another thread "DataSource(com.acme.Source)-2" a new stateful session is being created on the same RuleBase. This has already obtained the lock  (<0x189a8d88> (a java.util.HashMap)) that the Timer thread is waiting for, and is itself waiting for the another lock <0x189a2ba0> (a org.drools.reteoo.ReteooRuleBase) that the Timer thread has already locked, hence the deadlock.

In my own application I coded around this by eventually not using the RuleAgent in-built refresh mechanism, but instead periodically calling refreshRuleBase() on the RuleAgent in the SAME thread used to create the Stateful session, thus avoiding any deadlock.


"Timer-15" daemon prio=6 tid=0x02f4b0e8 nid=0x1864 waiting for monitor entry [0x038cf000..0x038cfa68]
	at org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:270)
	- waiting to lock <0x189a2ba0> (a org.drools.reteoo.ReteooRuleBase)
	at org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:656)
	at org.drools.common.AbstractRuleBase.removePackage(AbstractRuleBase.java:570)
	- locked <0x189a8d88> (a java.util.HashMap)
	at org.drools.agent.PackageProvider.removePackage(PackageProvider.java:45)
	at org.drools.agent.PackageProvider.applyChanges(PackageProvider.java:63)
	at org.drools.agent.RuleAgent.refreshRuleBase(RuleAgent.java:320)
	at org.drools.agent.RuleAgent$2.run(RuleAgent.java:438)
	at java.util.TimerThread.mainLoop(Unknown Source)
	at java.util.TimerThread.run(Unknown Source)



"DataSource(com.acme.Source)-2" daemon prio=4 tid=0x03027610 nid=0xfac waiting for monitor entry [0x0378f000..0x0378fb68]
	at org.drools.reteoo.ReteooRuleBase.newStatefulSession(ReteooRuleBase.java:225)
	- waiting to lock <0x189a8d88> (a java.util.HashMap)
	- locked <0x189a2ba0> (a org.drools.reteoo.ReteooRuleBase)
	at org.drools.common.AbstractRuleBase.newStatefulSession(AbstractRuleBase.java:284)
	at com.acme.RunRules.flush(RunRules.java:3337)
	at com.acme.ControlThread.run(ControlThread.java:465)
	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 09:08:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 09:08:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2168) CLONE
 -Deserializing a KnowledgeBase object throws a java.io.EOFException
Message-ID: <2122104211.1246972131431.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Deserializing a KnowledgeBase object throws a java.io.EOFException
-------------------------------------------------------------------------

                 Key: JBRULES-2168
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2168
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions:  5.0.0.M4, 5.0.0.M5
         Environment: Ubuntu 8.10
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


A java.io.EOFException is thrown when reading a serialized KnowledgeBase object from a file.

java.io.EOFException
	at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
	at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)
	at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
	at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:55)
	at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:49)
	at org.drools.common.AbstractRuleBase.readExternal(AbstractRuleBase.java:227)
	at org.drools.reteoo.ReteooRuleBase.readExternal(ReteooRuleBase.java:173)
	at org.drools.impl.KnowledgeBaseImpl.readExternal(KnowledgeBaseImpl.java:83)
	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
	at com.sample.DroolsTest.read(DroolsTest.java:75)
	at com.sample.DroolsTest.testIO(DroolsTest.java:50)
	at com.sample.DroolsTest.main(DroolsTest.java:40)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 09:14:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 09:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2169) CLONE -issue with
 using contains operator on array or collection of double (any )
Message-ID: <1932092042.1246972491518.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -issue with using contains operator on array or collection of double (any )
---------------------------------------------------------------------------------

                 Key: JBRULES-2169
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2169
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 4.0.7, 5.0.0.M3
         Environment: Windows XP service pack2
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


When using 'contains' operator on array or collection of strings its working fine. But when we use it for an array of primitive type double it gives a classcastexception . Is auto boxing not supported? May be this is fine as it mentioned in the documentation that it works only on Objects. I tried using the array of Double objects, here it doesn't throw an excpetion but the rule wasn't firing. The behaviour was same even if I use a collection of Double objects. 

 ex: 
using Array

     rule "OrderArray"
	 when

		 Order(valueArray contains 0)

	 then
             System.out.println("OrderArray");
end.

using Collection


 rule "OrderList"
	 when

		 Order(valueList contains 0)

	 then
             System.out.println("OrderList");
end.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 09:17:55 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 09:17:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2170) CLONE -Code
 completion in DSL in when-part does not work properly anymore
Message-ID: <1800180225.1246972675077.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Code completion in DSL in when-part does not work properly anymore
-------------------------------------------------------------------------

                 Key: JBRULES-2170
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2170
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse
    Affects Versions: 5.0.0.M5
         Environment: Eclipse 3.4, JRE 6u10, WinXP
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
             Fix For: 5.0.1.FINAL


When using the Code completion in an DSL-File-Editor in the when-part the completion does not work properly anymore.
It only shows up if you hit ALT-Space and have no character entered, so you can see the full list of "commands". But it's not possible to restrict that list using the beginning of a phrase.

In the then-part everything works find.

And it already worked in "when" using Drools 4.0.7 with Eclipse 3.3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 09:25:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 09:25:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2171) CLONE -No access
 to context in a constraint
Message-ID: <1547387351.1246973151491.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -No access to context in a constraint
-------------------------------------------

                 Key: JBRULES-2171
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2171
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.0.M5
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
             Fix For: 5.0.1.FINAL


Say I have a class Job with a method isFinished() that returns boolean. Also in a process context, I have a variable "job" of the type "Job". In a constraint on a split node, the following happens:

a) When the constraint is in mvel dialect, the code "((Job)job).finished" is correct.
b) When the constraint is in Java dialect, the code "Job j = (Job)(context.getVariable("job"));" gets me the following compilation error:

Process Compilation error : org.drools.lang.descr.ProcessDescr at 48f675
	[omitted] (27:1248) : context cannot be resolved

The documentation of this is quite clear: "Code constraints are expressions that return a boolean value. They have access to the context variable. MVEL code constraints also have direct access to the variables."

Therefore I think this is a bug.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 09:29:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 09:29:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2172) CLONE -DSL can't
 support Chinese characters problem
Message-ID: <225731935.1246973391424.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -DSL can't  support Chinese characters problem
----------------------------------------------------

                 Key: JBRULES-2172
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2172
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: All
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


I from Shanghai China. My Drools version is Drools5 M5. 

I get some errors from Drools ide  when I use Chinese characters in dsl file and use it in dslr file.

I think support Chinese characters is very important,so i hope drools team can fix this bug in next Drools version.

Thanks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 09:35:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 09:35:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2173) CLONE -Line break
 in DSL isnot generated anymore since Drools 5.0.0 CR1
Message-ID: <1749133183.1246973751893.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Line break in DSL isnot generated anymore since Drools 5.0.0 CR1
-----------------------------------------------------------------------

                 Key: JBRULES-2173
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2173
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 5.0.0.CR1
         Environment: jre6u12
eclipse 3.4
win xp
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


In Drools 4.0.7 and 5.0.0M5 it was possible to generate linebreaks using \n in an dsl-File.
Since 5.0.0 CR1 this is no longer possible: the \n is simply converted to the letter n which leads to compile-errors concerning the replaced code.

Example DSL:
# Test linebreak-bug since 5.0.0 CR1
[*][]only a simple test = System.out.println \n ("Did it generate a line break?");


Example DSLR:
#created on: 12.03.2009
package linebreak
expander linebreakbug.dsl
rule "line break bugtest"
  when
    #conditions
  then
  only a simple test
end


This leads to the line
System.out.println n ("Did it generate a line break?");


Maybe this bug is related to https://jira.jboss.org/jira/browse/JBRULES-1970 where the handling of #-Characters in DSL-Files had been fixed.

In my special case I'v got an workaround, but that's no workaround for anyone:
Using one DSLR I generate 2 Outputs:
a) using DSLR with dsl-file-A leads to "DLR"-Code: I don't need line breaks here (today, but maybe next month?)
   I don't care if the generated Code is nice or not and if the line is long or not.
   The code works and is executed by the rules-engine. Everything fine here.
  
b) using DSLR with dsl-file-B leads to programming-code in another programming-language. This Code is never executed in Drools, it is simply generated.
The result is taken an copied into the target-system. For that task I have written an own plugin that does that stuff and works like a little post-processor.
So my workaround is to use my own "keyword" $CRLF in an DSL-File and - after the generation that Drools does - replaced that with "\n".
Not where nice but simple...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 09:43:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 7 Jul 2009 09:43:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1076368575.1246974231483.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBXB-206:
---------------------------------

    Attachment: server-2.log.gz


> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>            Assignee: Alexey Loubyansky
>         Attachments: jboss-profiler.properties, jbossxb.zip, server-2.log.gz, server.log.gz
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 09:50:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 09:50:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2174) CLONE -DRL-Viewer
 does not keep position if refocused
Message-ID: <704590176.1246974651522.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -DRL-Viewer does not keep position if refocused
-----------------------------------------------------

                 Key: JBRULES-2174
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2174
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse
    Affects Versions: 5.0.0.CR1
         Environment: jre6u12
eclipse 3.4
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
            Priority: Minor
             Fix For: 5.0.1.FINAL


Using eclispe and working with an DSLR-File that depends an DSL-file.
The DSLR-File is a FormEditor (Multiparteditor) with 2 tabs: first tab for editing, 2nd one the "DRL Viewer".
Each time you navigate away and refocus that "DRL Viewer"-tab once again (with mouseclick) that view repositions the text to top / line 1.
That's very annoying if you have a bigger rulefile (that's the normal case) in is not state of the art (therefore I think this is a bug and not a feature request).
The viewer should keep it's position.

Suggestion: only change to top of text if viewer-content is regenerated / changed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 09:50:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 09:50:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2174) DRL-Viewer does
 not keep position if refocused
In-Reply-To: <704590176.1246974651522.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <663160494.1246974651607.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Neil Wallace updated JBRULES-2174:
----------------------------------

    Summary: DRL-Viewer does not keep position if refocused  (was: CLONE -DRL-Viewer does not keep position if refocused)


> DRL-Viewer does not keep position if refocused
> ----------------------------------------------
>
>                 Key: JBRULES-2174
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2174
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-eclipse
>    Affects Versions: 5.0.0.CR1
>         Environment: jre6u12
> eclipse 3.4
>            Reporter: Neil Wallace
>            Assignee: Kris Verlaenen
>            Priority: Minor
>             Fix For: 5.0.1.FINAL
>
>
> Using eclispe and working with an DSLR-File that depends an DSL-file.
> The DSLR-File is a FormEditor (Multiparteditor) with 2 tabs: first tab for editing, 2nd one the "DRL Viewer".
> Each time you navigate away and refocus that "DRL Viewer"-tab once again (with mouseclick) that view repositions the text to top / line 1.
> That's very annoying if you have a bigger rulefile (that's the normal case) in is not state of the art (therefore I think this is a bug and not a feature request).
> The viewer should keep it's position.
> Suggestion: only change to top of text if viewer-content is regenerated / changed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 09:56:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 09:56:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2175) CLONE -Using the
 "from" syntax
 in the when clause when running the "Drools Application" in debug mode
 takes longer than normal.
Message-ID: <1782935958.1246975011513.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Using the "from" syntax in the when clause when running the "Drools Application" in debug mode takes longer than normal. 
--------------------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2175
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2175
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


Just adding "t : Object() from m.getClass" to the drools project created by eclipse causes "builder.addPackageFromDrl( source );" to take about 48 seconds. if the from clause is not there it takes about 4 seconds.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 10:00:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2176) CLONE -multibyte
 characters in dsl  fails with "no viable alternative at character"
Message-ID: <439005257.1246975251577.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -multibyte characters in dsl  fails with "no viable alternative at character"
-----------------------------------------------------------------------------------

                 Key: JBRULES-2176
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2176
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler-DSL
    Affects Versions: 5.0.0.M1,  5.0.0.M2, 5.0.0.M3,  5.0.0.M4, 5.0.0.M5, 5.0.0.CR1
         Environment: Drools 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


Drools compiler fails to compile DSLs containing multibyte characters in them, says "no viable alternative at character".

----------
line 3:6 no viable alternative at character '?'
line 3:7 no viable alternative at character '?'

java.lang.NullPointerException
	at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:451)
	at org.drools.reteoo.ReteooRuleBase.addPackage(ReteooRuleBase.java:481)
	at org.drools.compiler.MultibyteDSLTest.testMultibyteDSL(MultibyteDSLTest.java:20)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
----------

http://lists.jboss.org/pipermail/rules-users/2009-March/008293.html


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 10:05:03 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2177) CLONE -NPE in
 compiler for fact class  w/o getters/setters
Message-ID: <1674151502.1246975503378.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -NPE in compiler for fact class  w/o getters/setters
----------------------------------------------------------

                 Key: JBRULES-2177
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2177
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler (expert)
    Affects Versions: 5.0.0.CR1
         Environment: any
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


A class with missing getters and setters, e.g.:
 public class Command {
	protected String  ident;
	protected Code    code;
	protected boolean refused;
	protected String  reason;
    public Command( String id, Code c ){
    	ident = id;
    	code  = c;
    }
}

used in a rule pattern such as, e.g.:
rule cleanupRefused
    when
        $c : Command( $i : ident, refused == true, $r : reason )
    then
        # whatever
end 

causes a NPE in Declaration:239 due to Declaration.readAccessor == null

This should produce a compiler error message.

NOTICE: Javadoc on constructors of class Declaration is incorrect!


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 10:10:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:10:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2178) CLONE -Rule
 failes to compile in 5.0 March 20th SNAPSHOT. Compiles ok in 4.07
Message-ID: <1914585082.1246975851502.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Rule failes to compile in 5.0 March 20th SNAPSHOT. Compiles ok in 4.07
-----------------------------------------------------------------------------

                 Key: JBRULES-2178
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2178
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
         Environment: Win Xp sp3
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


Attached code generates the following output. I would expect both rules to compile w/o an error.

Start
Fails
Rule Compilation error : [Rule name='a.b']
        test/Rule_a_b_0.java (11:488) : The method insert(Main) is undefined for the type Rule_a_b_0

Works
Done


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 10:16:51 2009
From: jira-events at lists.jboss.org (Michal Bali (JIRA))
Date: Tue, 7 Jul 2009 10:16:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2179) better
 integration of ruleflow and AgendaFilter
Message-ID: <438666444.1246976211719.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

better integration of ruleflow and AgendaFilter
-----------------------------------------------

                 Key: JBRULES-2179
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2179
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-core  (expert)
    Affects Versions: 5.0.1.FINAL
            Reporter: Michal Bali
            Assignee: Mark Proctor
             Fix For: 5.1.0.M1
         Attachments: agendaFilterWithRuleflow.zip

Hi,
I am creating this issue so that it won't be lost. See this post for more information: http://lists.jboss.org/pipermail/rules-users/2009-May/009110.html

My original email with one reply message is pasted below:
--------------------------------------------------------------
If a rule is not allowed to fire by an AgendaFilter the whole ruleflow stops. 

I've created a small test case (attached). It contains:
 - one DRL file with one dummy rule that is in some ruleflow-group.
 - one RF file with three nodes ('start', 'ruleflow group' and 'end')
 - a program that starts the process, and calls fireAllRules with custom agenda filter.

Once the program is executed the ruleflow will stop inside the ruleflow-group. If I remove the agenda filter it works as expected (the ruleflow finishes).

Tested with Drools 5.0.1.

Best regards,
Michal
----------------------------------------
Final reply from Mark:
It seems like a reasonable request, that if all the rules have been cancelled, fired or filtered that the ruleflow-group should be de-activated so the flow can continue. We'll look into it for 5.1.
---------------------------------------

Thanking you in advance,
Michal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 10:16:51 2009
From: jira-events at lists.jboss.org (Michal Bali (JIRA))
Date: Tue, 7 Jul 2009 10:16:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2179) better
 integration of ruleflow and AgendaFilter
In-Reply-To: <438666444.1246976211719.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <225468721.1246976211865.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michal Bali updated JBRULES-2179:
---------------------------------

    Attachment: agendaFilterWithRuleflow.zip


Attaching the original test case.

> better integration of ruleflow and AgendaFilter
> -----------------------------------------------
>
>                 Key: JBRULES-2179
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2179
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Michal Bali
>            Assignee: Mark Proctor
>             Fix For: 5.1.0.M1
>
>         Attachments: agendaFilterWithRuleflow.zip
>
>
> Hi,
> I am creating this issue so that it won't be lost. See this post for more information: http://lists.jboss.org/pipermail/rules-users/2009-May/009110.html
> My original email with one reply message is pasted below:
> --------------------------------------------------------------
> If a rule is not allowed to fire by an AgendaFilter the whole ruleflow stops. 
> I've created a small test case (attached). It contains:
>  - one DRL file with one dummy rule that is in some ruleflow-group.
>  - one RF file with three nodes ('start', 'ruleflow group' and 'end')
>  - a program that starts the process, and calls fireAllRules with custom agenda filter.
> Once the program is executed the ruleflow will stop inside the ruleflow-group. If I remove the agenda filter it works as expected (the ruleflow finishes).
> Tested with Drools 5.0.1.
> Best regards,
> Michal
> ----------------------------------------
> Final reply from Mark:
> It seems like a reasonable request, that if all the rules have been cancelled, fired or filtered that the ruleflow-group should be de-activated so the flow can continue. We'll look into it for 5.1.
> ---------------------------------------
> Thanking you in advance,
> Michal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 10:22:52 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:22:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2180) CLONE -Default
 Guvnor
 repository path in Eclipse webdav plugin differs from Guvnors actual path.
Message-ID: <1346048272.1246976572007.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Default Guvnor repository path in Eclipse webdav plugin differs from Guvnors actual path.
------------------------------------------------------------------------------------------------

                 Key: JBRULES-2180
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2180
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse, drools-guvnor
    Affects Versions: 5.0.0.CR1
         Environment: Windows XP SP3 with Sun JDK 1.5.0_15. Eclipse Version: 3.4.1 Build id: M20080911-1700. Note that the Guvnor was running under JBoss AS 4.2.2.
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
             Fix For: 5.0.1.FINAL


This isn't really a bug, but more of a configuration issue.

The default repository location displayed by the "Guvnor Repository Location" wizard in Eclipse is not the default location used by the Guvnor distributed under the drools project. Consequently, if you accept the default value in the wizard, it is likely you will not be able to connect to the repository running under the Guvnor. The default repository location in the wizard is:

    /jboss-brms/org.drools.guvnor.Guvnor/webdav

However, the default location to connect to the drools Guvnor is:

   /drools-guvnor/org.drools.guvnor.Guvnor/webdav

as the default URL for the Guvnor is: 

   http://localhost:8080/drools-guvnor/org.drools.guvnor.Guvnor/Guvnor.html

It is not obvious at first what is wrong, as if you accept the default repository location then the new location appears in the Guvnor Repositories view. But when you click on this repository name to browse it you get the following error:

"Server not reachable"

I initially assumed it was a network issue, or the wrong port (8080) etc. Only after careful inspection is it obvious that the default repository location in the Eclipse wizard does not match the default URL used by the drools Guvnor.

There has been some discussion related to this under the JIRA GUVNOR-120, but I'm not sure if there is a conflict between the solution suggested in that JIRA and the issue raised here.


To Reproduce Problem
============================

This assumes that the Guvnor is running locally at localhost:8080 which is the default location "out of the box".

1. Link to the Guvnor by selecting the menu option to run the "Guvnor Repository Location" wizard: File, New, Other, Guvnor, Guvnor Repository Location.

2. I accepted the defaults, adding only user and password:

Location: localhost
Port: 8080
Repository: /jboss-brms/org.drools.guvnor.Guvnor/webdav
User Name: admin
Password: admin
Selected to save password

Click Finish and the link is created successfully in the "Guvnor Repositories" view as:

http://localhost:8080/jboss-brms/org.drools.guvnor.Guvnor/webdav

3. Click on the link above. This causes the following error:

   "Server not reachable"

Notice that the URL for the link says jboss-brms instead of drools-guvnor.

4. Delete the link you just created and perform steps 1 and 2 again, but this time set the Repository value in step 2 as:

/drools-guvnor/org.drools.guvnor.Guvnor/webdav

5. Click on the new link above. This should allow you to browse the repository on the Guvnor side correctly.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 10:28:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:28:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2181) CLONE -Race
 conditions in AbstractRuleBase
Message-ID: <1783558499.1246976931541.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Race conditions in AbstractRuleBase
------------------------------------------

                 Key: JBRULES-2181
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2181
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core  (expert)
    Affects Versions: 5.0.0.CR1
         Environment: Windows, Drools CR1
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


ReteooRuleBaseMultiThreadedTest is failing because of race conditions in AbstractRuleBase

java.lang.NullPointerException
	at org.drools.common.AbstractRuleBase.lock(AbstractRuleBase.java:408)
	at org.drools.common.AbstractRuleBase.removePackage(AbstractRuleBase.java:655)
	at org.drools.reteoo.ReteooRuleBaseMultiThreadedTest$PackageModifier.doOperation(ReteooRuleBaseMultiThreadedTest.java:143)
	at org.drools.reteoo.ReteooRuleBaseMultiThreadedTest$BlockedThread.run(ReteooRuleBaseMultiThreadedTest.java:121)

junit.framework.AssertionFailedError: Exception in modifier thread expected:<false> but was:<true>
	at org.drools.reteoo.ReteooRuleBaseMultiThreadedTest.testNewSessionWhileModifyingRuleBase(ReteooRuleBaseMultiThreadedTest.java:80)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 10:32:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:32:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2182) CLONE -Problems
 with persistence of processes
Message-ID: <1709947390.1246977171747.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Problems with persistence of processes
---------------------------------------------

                 Key: JBRULES-2182
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2182
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core (flow)
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
             Fix For: 5.0.1.FINAL


Unmarshalling of persisted process instances containing variables failing.
Marshalling / unmarshalling or process instances as part of the session also does not use the pluggable process instance marshallers.
Working memory on unmarshalled process instances not set correctly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 10:36:52 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:36:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2183) CLONE -XOR Split
 not working properly inside CompositeNode
Message-ID: <832865011.1246977412514.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -XOR Split not working properly inside CompositeNode
----------------------------------------------------------

                 Key: JBRULES-2183
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2183
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core (flow)
    Affects Versions: 5.0.0.M5, 5.0.0.CR1
         Environment: java.version = 1.6.0_11
java.vm.name = Java HotSpot(TM) Client VM
Windows Vista Service Pack 1
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
             Fix For: 5.0.1.FINAL



If XOR Split node is used inside CompositeNode the following exception occurs regardless of the fact that at least one outgoing condition _is_ fulfilled:

java.lang.IllegalArgumentException: XOR split could not find at least one valid outgoing connection for split Split
	at org.drools.workflow.instance.node.SplitInstance.internalTrigger(SplitInstance.java:72)
	at org.drools.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:111)
	at org.drools.workflow.instance.impl.NodeInstanceImpl.triggerConnection(NodeInstanceImpl.java:141)
	at org.drools.workflow.instance.impl.NodeInstanceImpl.triggerCompleted(NodeInstanceImpl.java:128)
	at org.drools.workflow.instance.node.ActionNodeInstance.triggerCompleted(ActionNodeInstance.java:62)
	at org.drools.workflow.instance.node.ActionNodeInstance.internalTrigger(ActionNodeInstance.java:58)
	at org.drools.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:111)

The accompanying attachment 'drools-xor-bug.zip' contains an example that reproduces the problem. 

Zip file contains the eclipse project - simply import it in Eclipse and run com.sample.RuleFlowTest.java.

There are two .rf files. normalXOR.rf contains a working process, using XOR Split outside of CompositeNode. weirdXOR.rf contains the same XOR Split branching and outgoing constraints, but is positioned within CompositeNode.

RuleFlowTest first successfully executes normalXOR flow, then fails while executing weirdXOR flow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 10:40:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:40:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2184) CLONE -Update
 causes query to return no results
Message-ID: <1502951677.1246977651732.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Update causes query to return no results
-----------------------------------------------

                 Key: JBRULES-2184
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2184
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


I've found a weird scenario where a simple query which is returning the correct data, stops returning anything if you invoke update on one of the facts that it depends on.  If you use retract/insert instead of update then it works fine.  The problem only seems to occur if there is an inheritance relationship between the objects in the query.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 10:44:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:44:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2185) CLONE -Collection
 returned by
 StatefulKnowledgeSession.getObjects() doesn't conform to standard
 collection behaviour
Message-ID: <1930341947.1246977891526.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Collection returned by StatefulKnowledgeSession.getObjects() doesn't conform to standard collection behaviour
--------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2185
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2185
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


StatefulKnowledgeSession.getObjects() returns a collection containing the objects in working memory.

The Javadoc for Collection.contains says:

"Returns true if this collection contains the specified element. More formally, returns true if and only if this collection contains at least one element e such that (o==null ? e==null : o.equals(e)). "

This is not the case though for StatefulKnowledgeSessionImpl.ObjectStoreWrapper.  The implementation of contains returns true only if it is the exact same object instance, but false if it is a different instance but which equals the instance in the working memory.

A workaround is to create a new collection and put the items returned into that.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 10:50:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:50:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2186) CLONE
 -declaration of 2
 variables in the init part of accumulate is not possible
Message-ID: <220881410.1246978251476.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -declaration of 2 variables in the init part of accumulate is not possible
--------------------------------------------------------------------------------

                 Key: JBRULES-2186
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2186
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


Take a rule with 2 variables int the init part, like
		$maxCa:CompanyCA() from accumulate($ca:CompanyCA($year:year) from $p.cas, 
										init(ecrm.party.CompanyCA currentCA=null;int maxYear = 0;),
										action(maxYear = Math.max(maxYear, $year);),
										result(currentCA)); 
which can return the year and the ca where the ca is max.

It won't compile with the error that company CA is not declare.

The bug is in the class org.drools.rule.builder.dialect.java.JavaAccumulateBuilder
line 194
            int index = 0;
            for ( Iterator it = initCodeAnalysis.getLocalVariablesMap().entrySet().iterator(); it.hasNext(); ) {
                Map.Entry entry = (Map.Entry) it.next();
                attributes[index] = (String) entry.getKey();
                attributesTypes[index] = ((JavaLocalDeclarationDescr) entry.getValue()).getType();
            }
when the variables are put in the context, only the first is put (index stay at 0)

We should increment the index
            int index = 0;
            for ( Iterator it = initCodeAnalysis.getLocalVariablesMap().entrySet().iterator(); it.hasNext(); ) {
                Map.Entry entry = (Map.Entry) it.next();
                attributes[index] = (String) entry.getKey();
                attributesTypes[index] = ((JavaLocalDeclarationDescr) entry.getValue()).getType();
                index ++;
            }









-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 10:54:55 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:54:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2187) CLONE -Unusable
 error message
 during test scnario execution: Exception executing predicate
 org.drools.base.mvel.MVELPredicateExpression@739c6e
Message-ID: <1008630844.1246978495815.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Unusable error message during test scnario execution: Exception executing predicate org.drools.base.mvel.MVELPredicateExpression at 739c6e
----------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2187
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2187
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-guvnor
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Mark Proctor
            Priority: Minor
             Fix For: 5.0.1.FINAL


With Guvnor 5.0.0.CR1 it seems that I have produced an error in a decision table which only appears during test scenario execution.
However the error message given in the browser (and on the console) is not very helpful:
{code}
2009-04-17 15:31:28,691 INFO  [STDOUT] ERROR 17-04 15:31:28,690 (ServiceImplementation.java:runScenario:1875)    org.drools.RuntimeDroolsException: Exception executing predicate org.drools.base.mvel.MVELPredicateExpression
{code}

As far as I know it's possible to extract the actual expression from MVELPredicateExpression and it would be nice if this gets printed so that users have a chance of fixing the problem. ;-)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 10:54:58 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 7 Jul 2009 10:54:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7052) when invoked from
 remote
 client, call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <783570980.1246978498264.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475222#action_12475222 ] 

Scott Marlow commented on JBAS-7052:
------------------------------------

Ian, this jira is not assigned to me but I wanted to try helping with a few questions.

I read the above jira information and am left wondering a few things.  I assume that you already put in effort to resolve this on your own, so please help me answer these questions:

1.  Does the above exception occur after the server side getComponentsForType() has been invoked?  I assume yes and that this is caused by the handling of the getComponentsForType() result object being returned.

2.  Assuming that this is caused by the result value from the getComponentsForType(), what classes are being returned?  

3.  If you know, can you tell me why the org.jboss.profileservice.management.ManagedOperationDelegate class is being referenced in the above call stack?  

> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 10:58:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 10:58:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2188) CLONE -MVEL
 consequences + modify call == NPE
Message-ID: <1921784687.1246978731623.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -MVEL consequences + modify call == NPE
---------------------------------------------

                 Key: JBRULES-2188
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2188
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


PetStore example is raising NPE because of a rule with MVEL dialect that contains a modify() call in the consequence.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 11:09:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:09:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2189) CLONE -MVEL debug
 not working anymore
Message-ID: <521726479.1246979391872.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -MVEL debug not working anymore
-------------------------------------

                 Key: JBRULES-2189
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2189
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
             Fix For: 5.0.1.FINAL


When debugging rules using the MVEL dialect, Eclipse cannot find the right MVEL source and line number to show when encountering a breakpoint in MVEL code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 11:13:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:13:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2190) CLONE -Decision
 table web editor does not remember column configuration
Message-ID: <822610486.1246979631859.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Decision table web editor does not remember column configuration
-----------------------------------------------------------------------

                 Key: JBRULES-2190
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2190
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-guvnor
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Michael Neale
            Priority: Minor
             Fix For: 5.0.1.FINAL


When reconfiguring columns  (grouping, sorting, hiding of columns)in the guided/ web decision table editor, this configuration is lost if that editor is closed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 11:17:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2191) CLONE
 -update(fact) doesn't work in ruleflow
Message-ID: <1018830665.1246979871500.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -update(fact) doesn't work in ruleflow
--------------------------------------------

                 Key: JBRULES-2191
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2191
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core  (expert), drools-core (flow)
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Kris Verlaenen
            Priority: Critical
             Fix For: 5.0.1.FINAL


Hi,
org.drools.base.DefaultKnowledgeHelper uses newly added identityMap to keep track of fact handles. It looks like this identityMap is updated before a rule's consequence is called. However it is not updated before a Drools Flow on-exit action. This means that calling update(someFact) in a on-exit ruleflow action causes exception ("org.drools.FactException: Update error: handle not found for object: XXXXX. Is it in the working memory?"). 

this was tested on drools-core-5.0.0.20090417.044049-485.jar

Thanking you in advance.
Best Regards,
Michal


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 11:22:03 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2192) CLONE -Eclipse
 regression for MVEL debugging
Message-ID: <1685295764.1246980123767.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Eclipse regression for MVEL debugging
--------------------------------------------

                 Key: JBRULES-2192
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2192
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse (expert)
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


probably relate to an MVEL change.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 11:25:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:25:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2193) CLONE -Modify
 raises NPE when using "from"
Message-ID: <1318734644.1246980351600.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Modify raises NPE when using "from"
------------------------------------------

                 Key: JBRULES-2193
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2193
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


The attached file should generate everyting into a subdirectory ./movie and compile and execute.

You'll have to modify the classpath, though.

Regards
-W


# Shell this file to create subdir movie with *.java, Movie.drl, database.xml
#
# you'll have to modify the classpath setting - see below
#

mkdir movie || true

cat <<'TheEnd' >movie/Main.java
package movie;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.InputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.OutputStream;
import java.util.Collection;

import javax.xml.bind.JAXBContext;

import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderError;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.builder.ResourceType;
import org.drools.definition.KnowledgePackage;
import org.drools.io.ResourceFactory;
import org.drools.runtime.StatefulKnowledgeSession;

import javax.xml.bind.Unmarshaller;

public class Main {

       private StatefulKnowledgeSession session;

       public Main(){
       }

       public void init() throws Exception {

       KnowledgeBase kBase = KnowledgeBaseFactory.newKnowledgeBase();
       KnowledgeBuilder kBuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
       kBuilder.add( ResourceFactory.newFileResource( "movie/Movie.drl" ),
                     ResourceType.DRL );
       if( kBuilder.hasErrors() ){
               for( KnowledgeBuilderError err: kBuilder.getErrors() ){
                       System.out.println( err.toString() );
               }
               throw new IllegalStateException( "DRL errors" );
       }

       kBase.addKnowledgePackages( kBuilder.getKnowledgePackages() );

               File xml = new File( "database.xml" );
               JAXBContext jc = JAXBContext.newInstance( Database.class );
               Unmarshaller u = jc.createUnmarshaller();
               InputStream inputStream = new FileInputStream( xml );
               Database db = (Database)u.unmarshal( inputStream );
               inputStream.close();

       session = kBase.newStatefulKnowledgeSession();

               for( Movie m: db.getMovie() ){
                       session.insert( m );
               }
               for( Actor a: db.getActor() ){
                       session.insert( a );
               }
               for( Role r: db.getRole() ){
                       session.insert( r );
               }
               session.fireAllRules();
       }

       public static void main( String[] args ) throws Exception {
               Main rf = new Main();
               rf.init();
       }

}
TheEnd

cat <<'TheEnd' >movie/Role.java
package movie;

import javax.xml.bind.annotation.XmlAttribute;

public class Role implements Item {

       private String actor;
       private String movie;

       public Role(){
       }

       @XmlAttribute
       public String getActor() {
               return actor;
       }

       public void setActor(String actor) {
               this.actor = actor;
       }

       @XmlAttribute
       public String getMovie() {
               return movie;
       }

       public void setMovie(String movie) {
               this.movie = movie;
       }

       @Override
       public String toString(){
               return actor + " plays in " + movie;
       }

}
TheEnd

cat <<'TheEnd' >movie/Movie.java
package movie;

import java.util.HashSet;
import java.util.Set;
import javax.xml.bind.annotation.XmlAttribute;

public class Movie implements Item {
       private String title;
       private Set<Actor> cast;

       public Movie(){
       }

       @XmlAttribute
       public String getTitle() {
               return title;
       }
       public void setTitle(String title) {
               this.title = title;
       }

       public Set<Actor> getCast(){
               if( cast == null ) cast = new HashSet<Actor>();
               return cast;
       }

       @Override
       public int hashCode(){
               return title.hashCode();
       }

       @Override
       public boolean equals( Object o ){
               if( ! (o instanceof Movie ) ) return false;
               return this.title.equals( ((Movie)o).getTitle() );
       }

       @Override
       public String toString(){
               StringBuilder sb = new StringBuilder();
               sb.append( title ).append( "\n" );
               for( Actor a: getCast() ){
                       sb.append( "  " ).append( a.getName() ).append( "\n" );
               }
               return sb.toString();
       }
}
TheEnd

cat <<'TheEnd' >movie/Item.java
package movie;

/**
 * Marker interface for WMEs
 * @author Wolfgang Laun
 */
public interface Item {
}
TheEnd

cat <<'TheEnd' >movie/Database.java
package movie;

import java.util.ArrayList;
import java.util.List;

import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;

@XmlRootElement
@XmlType(propOrder={"movie", "actor" , "role" })
public class Database {

       private List<Movie> movie;
       private List<Actor> actor;
       private List<Role> role;

       public Database(){
       }

       @XmlElement
       public List<Movie> getMovie() {
               if( movie == null ) movie = new ArrayList<Movie>();
               return movie;
       }

       @XmlElement
       public List<Actor> getActor() {
               if( actor == null ) actor = new ArrayList<Actor>();
               return actor;
       }

       @XmlElement
       public List<Role> getRole() {
               if( role == null ) role = new ArrayList<Role>();
               return role;
       }

}
TheEnd

cat <<'TheEnd' >movie/Actor.java
package movie;

import java.util.ArrayList;
import java.util.List;
import javax.xml.bind.annotation.XmlAttribute;

public class Actor implements Item {

       private String name;
       private List<Movie> movies;

       public Actor(){
       }

       @XmlAttribute
       public String getName() {
               return name;
       }
       public void setName(String name) {
               this.name = name;
       }

       public List<Movie> getMovies(){
               if( movies == null ) movies = new ArrayList<Movie>();
               return movies;
       }

       @Override
       public String toString(){
               StringBuilder sb = new StringBuilder();
               sb.append( name ).append( "\n" );
               for( Movie m: getMovies() ){
                       sb.append( "  " ).append( m.getTitle() ).append( "\n" );
               }
               return sb.toString();
       }

       @Override
       public int hashCode(){
               return name.hashCode();
       }

       @Override
       public boolean equals( Object o ){
               if( ! (o instanceof Actor ) ) return false;
               return this.name.equals( ((Actor)o).getName() );
       }
}
TheEnd

cat <<'TheEnd' >movie/Movie.drl
package movie;

/***
 - List<?> as fact field type
 - Set<?> as fact field type
 - Match WMEs with elements from field with List<?> type: from
 - inline eval() for determining membership in Collection()
 - Write rules for a set of WME types using a "marker" interface.

*/

#
# Fill the Movies' cast lists with data from Role.
#
rule fillCast
   salience 100
   when
       $r : Role( $actor : actor, $movie : movie )
       $a : Actor( name == $actor )
       $m : Movie( title == $movie )
   then
       modify( $m ){
           getCast().add( $a );
       }
       retract( $r );
end

#
# Fill the Actors' list of movies with data from a Movie's cast list
#
rule fillMovies
   salience 90
   when
       $m : Movie( $cast : cast )
       $a : Actor() from $cast
   then
       System.out.println( "movie " + $m.getTitle() + " actor " + $a.getName() );
       modify( $a ){
           getMovies().add( $m );
       }
end

#
# Find a movie where HB and LB are in together
#
rule findHBLB
   when
       $hb : Actor( name == "Humphrey Bogart" )
       $lb : Actor( name == "Lauren Bacall" )
       $m : Movie( $title : title, $cast : cast, eval( $cast.contains( $hb ) && $cast.contains( $lb ) ) )
   then
       System.out.println( "HB & LB together in " + $title );
end

#
# Display any WME
#
rule showItem
   salience -100
   when
       $i : Item()
   then
       System.out.println( $i.toString() );
end
TheEnd

cat <<'TheEnd' >database.xml
<?xml version="1.0" encoding="UTF-8"?>
<database>
<movie title="Casablanca"/>
<movie title="Key Largo"/>
<movie title="To Have and Have Not"/>
<movie title="The African Queen"/>
<actor name="Humphrey Bogart"/>
<actor name="Katherine Hepburn"/>
<actor name="Ingrid Bergman"/>
<actor name="Lauren Bacall"/>
<role actor="Humphrey Bogart" movie="Casablanca"/>
<role actor="Ingrid Bergman"  movie="Casablanca"/>
<role actor="Humphrey Bogart" movie="The African Queen"/>
<role actor="Humphrey Bogart" movie="Key Largo"/>
<role actor="Humphrey Bogart" movie="To Have and Have Not"/>
<role actor="Lauren Bacall" movie="To Have and Have Not"/>
<role actor="Lauren Bacall" movie="Key Largo"/>
<role actor="Katherine Hepburn" movie="The African Queen"/>
</database>
TheEnd

export CLASSPATH=.:/extra/Drools-5.0.1.SNAPSHOT/drools-core.jar:/extra/Drools-5.0.1.SNAPSHOT/drools-api.jar:/extra/Drools-5.0.1.SNAPSHOT/drools-compiler.jar:/extra/Drools-5.0.1.SNAPSHOT/drools-ant.jar:/extra/Drools-5.0.1.SNAPSHOT/antlr-runtime.jar:/usr/local/eclipse/plugins/org.eclipse.jdt.core_3.4.4.v_894_R34x.jar:/extra/Drools-5.0.0.CR1/bin/lib/mvel2-2.0.8pre1.jar

javac movie/*.java

java movie/Main

cat <<'TheEnd'

#
# This is what I get:
#

movie Casablanca actor Ingrid Bergman
Exception in thread "main" org.drools.runtime.rule.ConsequenceException: java.lang.NullPointerException
       at org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:23)
       at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:943)
       at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:885)
       at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1086)
       at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:682)
       at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:649)
       at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:183)
       at movie.Main.init(Main.java:65)
       at movie.Main.main(Main.java:70)
Caused by: java.lang.NullPointerException
       at org.drools.base.DefaultKnowledgeHelper.modifyRetract(DefaultKnowledgeHelper.java:190)
       at movie.Rule_fillMovies_0.consequence(Rule_fillMovies_0.java:8)
       at movie.Rule_fillMovies_0ConsequenceInvoker.evaluate(Rule_fillMovies_0ConsequenceInvoker.java:28)
       at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:934)
       ... 7 more
TheEnd

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 11:29:52 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:29:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2194) CLONE
 -StatelessKnowledgeSessions created by KnowledgeAgent causes
 NullPointerException when used in a pipeline
Message-ID: <1933041400.1246980592620.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -StatelessKnowledgeSessions created by KnowledgeAgent causes NullPointerException when used in a pipeline
---------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2194
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2194
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
         Environment: 5.0.1.SNAPSHOT for May 12, 2009
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


This issue is related to this thread on the user-list:  http://www.mail-archive.com/rules-users at lists.jboss.org/msg08770.html

I'm getting a NullPointerException when I insert an object into
the pipeline using 5.0.1.SNAPSHOT from May 12, 2009:
java.lang.NullPointerException
        at 
org.drools.runtime.pipeline.impl.StatelessKnowledgeSessionPipelineImpl.insert(StatelessKnowledgeSessionPipelineImpl.java:24)

It looks like StatelessKnowledgeSession's ruleBase is null when created by the KnowledgeAgent, which poses a problem since StatelessKnowledgeSessionPipelineImpl invokes getRootClassLoader() on the session's ruleBase.

Here's what I'm doing:
StatelessKnowledgeSession ksession = kagent.newStatelessKnowledgeSession();
Pipeline pipeline =
PipelineFactory.newStatelessKnowledgeSessionPipeline(ksession);
pipeline.setReceiver(messageTransformer);
pipeline.insert(message);  // NPE here

I'll attach a patch to KnowledgeAgentTest containing a failing test case.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 11:31:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:31:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2195) CLONE -Memory
 leak on queries (regression)
Message-ID: <266952686.1246980711658.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Memory leak on queries (regression)
------------------------------------------

                 Key: JBRULES-2195
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2195
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.0.M5, 5.0.0.CR1
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


A leak was found when a rulebase contained 2 or more queries on it.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 11:35:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:35:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2196) CLONE -Improve
 handling of value coercion into BigDecimal and BigInteger
Message-ID: <730394005.1246980951577.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Improve handling of value coercion into BigDecimal and BigInteger
------------------------------------------------------------------------

                 Key: JBRULES-2196
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2196
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler, drools-core
    Affects Versions: 5.0.0.M5, 5.0.0.CR1, 5.0.0.FINAL
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.1.FINAL


Handle coercion into BigDecimal and BigInteger properly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 11:41:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:41:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2198) CLONE
 -fireAllRules() blocks if called while fireUntilHalt() is running
Message-ID: <1273282122.1246981311589.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -fireAllRules() blocks if called while fireUntilHalt() is running
-----------------------------------------------------------------------

                 Key: JBRULES-2198
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2198
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
            Reporter: Neil Wallace
            Assignee: Edson Tirelli
             Fix For: 5.0.2, 5.1.0.M1


Drools work items call fireAllRules() automatically after completion. If the engine is already running fireUntilHalt() though, it blocks.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 11:39:51 2009
From: jira-events at lists.jboss.org (Neil Wallace (JIRA))
Date: Tue, 7 Jul 2009 11:39:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2197) CLONE -Example
	source.
Message-ID: <2031554791.1246981191511.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE -Example source.
----------------------

                 Key: JBRULES-2197
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2197
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 5.0.1.FINAL
         Environment: Windows XP,eclipse
            Reporter: Neil Wallace
            Assignee: Mark Proctor
             Fix For: 5.0.1.FINAL


Hi! We are studying Drools 5.0 in order to use..
But a curious problem has happened, while executeing an example in documentation.

It is 3.1.3. Defining Processes Using the Process API in drools-5.0-docs\drools-flow\html_single\index.html.
Actually, 3.1.3.1. Example 1 is working normally, but 3.1.3.2. Example 2 and 3.1.3.3. Example 3 occur error.
I 'll tell you what we grasp the reason for error, so far.

When it's working normal, <ActionNode> exists.
The other way, when it is not working normal, <ActionNode> doesn't exist.
For example, in case of 3.1.3.2. Example 2

RuleFlowProcessFactory factory =
    RuleFlowProcessFactory.createProcess("org.drools.HelloWorldJoinSplit");
factory
    // Header
    .name("HelloWorldJoinSplit")
    .version("1.0")
    .packageName("org.drools")
    // Nodes
    .startNode(1).name("Start").done()
    .splitNode(2).name("Split").type(Split.TYPE_AND).done()
    .actionNode(3).name("Action 1")
        .action("mvel", "System.out.println(\"Inside Action 1\")").done()                <       -here, NullPointerException occurs.
    .actionNode(4).name("Action 2")
        .action("mvel", "System.out.println(\"Inside Action 2\")").done()
    .joinNode(5).type(Join.TYPE_AND).done()
    .endNode(6).name("End").done()
    // Connections
    .connection(1, 2)
    .connection(2, 3)
    .connection(2, 4)
    .connection(3, 5)
    .connection(4, 5)
    .connection(5, 6);
RuleFlowProcess process = factory.validate().getProcess();


Please, let me know entire source I can execute this example well.

Thank you for your consideration.

I am waiting for you answer.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 11:45:51 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Jul 2009 11:45:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1678) OME on the
 Journal when processing too many files
Message-ID: <2117713915.1246981551955.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

OME on the Journal when processing too many files
-------------------------------------------------

                 Key: JBMESSAGING-1678
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1678
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0.beta3, 2.0.0.beta2, 2.0.0 Beta1
            Reporter: Clebert Suconic
            Assignee: Clebert Suconic
             Fix For: 2.0.0


Set one producer.. sending one message / second (about 200 messages)

Set another producer/consumer (in another destination) sending as fast as it can. (about 500K messages).

At the end you will have 200 files... but only 200 messages (one valid on each file).

This will lead to an OME.



On trunk, you need to deactivate compacting to replicate this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 11:45:52 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Jul 2009 11:45:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1678) OME on the
 Journal when processing too many files
In-Reply-To: <2117713915.1246981551955.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1362307618.1246981552101.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1678:
-----------------------------------------

    Description: 
Set one producer.. sending one message / second (about 200 messages)

Set another producer/consumer (in another destination) sending as fast as it can. (about 500K messages).

At the end you will have 200 files... but only 200 messages (one valid on each file).

This will lead to an OME during reload.



On trunk, you need to deactivate compacting to replicate this.

  was:
Set one producer.. sending one message / second (about 200 messages)

Set another producer/consumer (in another destination) sending as fast as it can. (about 500K messages).

At the end you will have 200 files... but only 200 messages (one valid on each file).

This will lead to an OME.



On trunk, you need to deactivate compacting to replicate this.



> OME on the Journal when processing too many files
> -------------------------------------------------
>
>                 Key: JBMESSAGING-1678
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1678
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2, 2.0.0.beta3
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Set one producer.. sending one message / second (about 200 messages)
> Set another producer/consumer (in another destination) sending as fast as it can. (about 500K messages).
> At the end you will have 200 files... but only 200 messages (one valid on each file).
> This will lead to an OME during reload.
> On trunk, you need to deactivate compacting to replicate this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 11:56:51 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 7 Jul 2009 11:56:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7052) when invoked from
 remote
 client, call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <997687701.1246982211650.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475234#action_12475234 ] 

Scott M Stark commented on JBAS-7052:
-------------------------------------

I'm breaking out the classes we return to clients into a jboss-profileservice-client.jar for inclusion on the client classpath. We return these delegate objects when we create proxies for runtime operations and properties that need to be dispatched to a server side component.


> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 12:14:51 2009
From: jira-events at lists.jboss.org (Adrian Woodhead (JIRA))
Date: Tue, 7 Jul 2009 12:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1679)
 http://wiki.jboss.org/wiki/Wiki.jsp?page=HelpBugReport
Message-ID: <318505980.1246983291590.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

http://wiki.jboss.org/wiki/Wiki.jsp?page=HelpBugReport
------------------------------------------------------

                 Key: JBMESSAGING-1679
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1679
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0.beta3
            Reporter: Adrian Woodhead
            Assignee: Tim Fox


Refer to http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242246#4242246 for more information, stack trace etc.

In essence the problem seems to be messages with an expiry time set seem to have problems when pre-ack mode is used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 12:14:51 2009
From: jira-events at lists.jboss.org (Adrian Woodhead (JIRA))
Date: Tue, 7 Jul 2009 12:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1679) Could not
 find reference with id
In-Reply-To: <318505980.1246983291590.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <595842045.1246983291866.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adrian Woodhead updated JBMESSAGING-1679:
-----------------------------------------

    Summary: Could not find reference with id  (was: http://wiki.jboss.org/wiki/Wiki.jsp?page=HelpBugReport)


> Could not find reference with id
> --------------------------------
>
>                 Key: JBMESSAGING-1679
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1679
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>            Reporter: Adrian Woodhead
>            Assignee: Tim Fox
>
> Refer to http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242246#4242246 for more information, stack trace etc.
> In essence the problem seems to be messages with an expiry time set seem to have problems when pre-ack mode is used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 13:37:51 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 7 Jul 2009 13:37:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7083) Add bean to install
 executor in AbstractController to as bootstrap
Message-ID: <1299419994.1246988271497.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add bean to install executor in AbstractController to as bootstrap
------------------------------------------------------------------

                 Key: JBAS-7083
                 URL: https://jira.jboss.org/jira/browse/JBAS-7083
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For: JBossAS-6.0.0.Alpha1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 13:37:51 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 7 Jul 2009 13:37:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7083) Add bean to install
 executor in AbstractController to as bootstrap
In-Reply-To: <1299419994.1246988271497.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1295859546.1246988271558.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed JBAS-7083.
----------------------------

    Resolution: Done


> Add bean to install executor in AbstractController to as bootstrap
> ------------------------------------------------------------------
>
>                 Key: JBAS-7083
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7083
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: JBossAS-6.0.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 13:48:51 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 7 Jul 2009 13:48:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7083) Add bean to
 install executor in AbstractController to as bootstrap
In-Reply-To: <1299419994.1246988271497.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <643703691.1246988931520.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475263#action_12475263 ] 

Kabir Khan commented on JBAS-7083:
----------------------------------

To actually see the asynch behaviour, an MC version containing JBKERNEL-25 is needed

> Add bean to install executor in AbstractController to as bootstrap
> ------------------------------------------------------------------
>
>                 Key: JBAS-7083
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7083
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: JBossAS-6.0.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 13:59:51 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Jul 2009 13:59:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1935333346.1246989591757.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic reassigned JBMESSAGING-1677:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)


> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Clebert Suconic
>         Attachments: JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 13:59:51 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Jul 2009 13:59:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1407983860.1246989591888.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1677.
----------------------------------------

    Resolution: Cannot Reproduce Bug


> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Clebert Suconic
>         Attachments: JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 14:48:51 2009
From: jira-events at lists.jboss.org (Art Plata (JIRA))
Date: Tue, 7 Jul 2009 14:48:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1661) Messages in
 JBoss 5.1
 that use bridging get stuck in a devlivering mode and are not sent to the
 remote cluster
In-Reply-To: <29236051.1245359337536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1620742860.1246992531548.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475272#action_12475272 ] 

Art Plata commented on JBMESSAGING-1661:
----------------------------------------

http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157886

> Messages in JBoss 5.1 that use bridging get stuck in a devlivering mode and are not sent to the remote cluster
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1661
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1661
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.3.GA
>         Environment: Linux -- JBoss 5.1 GA / JBM 1.4.3GA / Remoting 2.5.1
>            Reporter: Peter Crossley
>            Assignee: Howard Gao
>             Fix For: 1.4.5.GA
>
>
> A Message bridge between to clusters will get in to a state where the messages will not be picked up by the bridge on the topic/queue and remain in the "delivering" counter until the bridge is restarted via the JMX console or by restarting the Jboss instance.
> I attempted to use JBM 1.4.4 which has a fix (JBMESSAGING-1456) that seems to be the same issue, though do to the difference in the remoting I cannot use the 1.4.4 GA release.
> Can we get the fixes that were applied to the 1.4.4 release in a usable build for JBoss AS 5.1

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 15:14:51 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 7 Jul 2009 15:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <15950453.1246994091517.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475277#action_12475277 ] 

Stan Silvert commented on JBAS-7032:
------------------------------------

Shelly, I reproduced the NPE you were talking about:

12:36:01,025 ERROR [Digester] End event threw exception
java.lang.reflect.InvocationTargetException
        at sun.reflect.GeneratedMethodAccessor289.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:216)
        at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:217)
        at org.apache.commons.digester.Rule.end(Rule.java:253)
        at org.apache.commons.digester.Digester.endElement(Digester.java:1222)

Caused by: java.lang.NullPointerException
        at org.ajax4jsf.resource.InternetResourceBase.restoreData(InternetResourceBase.java:248)
        at org.richfaces.renderkit.html.Paint2DResource.getRenderer(Paint2DResource.java:68)
        at org.ajax4jsf.resource.ResourceBuilderImpl.addResource(ResourceBuilderImpl.java:406)

This is easily reproduced by just cold-deploying the EAR attached to this JIRA.  However, this EAR has several web jars that are in WhatUpDawg.ear/lib that probably shouldn't be there.  I moved these to WhatUpDawg.ear/WhatUpDawg.war/WEB-INF/lib:
jsf-facelets.jar
jsf-tlds.jar (You shouldn't need this because the server exposes a global copy)
jstl.jar (You shouldn't need this because the server exposes a global copy)
richfaces-api-3.3.1.GA.jar
richfaces-impl-3.3.1.GA.jar
richfaces-ui-3.3.1.GA.jar

So with these "web" jars in the proper place, Shelly's problem goes away.  Was there some reason that you wanted to move Facelets and RichFaces outside of the war?

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 17:01:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 7 Jul 2009 17:01:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-95) Create server states
 to account for callbacks before and after server init
Message-ID: <1641073694.1247000511604.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Create server states to account for callbacks before and after server init
--------------------------------------------------------------------------

                 Key: JBBOOT-95
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-95
             Project: JBoss Bootstrap
          Issue Type: Task
          Components: impl-base, spi
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger


We need to be able to have lifecycle callbacks take place either right before or right after server initialization.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 17:03:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 7 Jul 2009 17:03:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-95) Create server states
 to account for callbacks before and after server init
In-Reply-To: <1641073694.1247000511604.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1600191925.1247000631682.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated JBBOOT-95:
--------------------------------------

    Fix Version/s: impl-base-2.0.0-alpha-2
                   spi-2.0.0-alpha-2 


> Create server states to account for callbacks before and after server init
> --------------------------------------------------------------------------
>
>                 Key: JBBOOT-95
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-95
>             Project: JBoss Bootstrap
>          Issue Type: Task
>          Components: impl-base, spi
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: impl-base-2.0.0-alpha-2, spi-2.0.0-alpha-2 
>
>
> We need to be able to have lifecycle callbacks take place either right before or right after server initialization.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 17:23:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 7 Jul 2009 17:23:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-95) Create server
 states to account for callbacks before and after server init
In-Reply-To: <1641073694.1247000511604.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <357280608.1247001831562.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-95.
---------------------------------------

    Resolution: Done


> Create server states to account for callbacks before and after server init
> --------------------------------------------------------------------------
>
>                 Key: JBBOOT-95
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-95
>             Project: JBoss Bootstrap
>          Issue Type: Task
>          Components: impl-base, spi
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: impl-base-2.0.0-alpha-2, spi-2.0.0-alpha-2 
>
>
> We need to be able to have lifecycle callbacks take place either right before or right after server initialization.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 17:37:51 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Jul 2009 17:37:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1678) OME on the
 Journal when processing too many files
In-Reply-To: <2117713915.1246981551955.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1512107454.1247002671522.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475298#action_12475298 ] 

Clebert Suconic commented on JBMESSAGING-1678:
----------------------------------------------

This is because the method load has two lists:

      final Set<Long> recordsToDelete = new HashSet<Long>();
      final List<RecordInfo> records = new ArrayList<RecordInfo>();


The method load will add to both recordsToDelete and records.  At the end of the method, it will only consider the records that were not deleted:

      for (RecordInfo record : records)
      {
         if (!recordsToDelete.contains(record.id))
         {
            committedRecords.add(record);
         }
      }



But In a scenario where compacting is not working, records and recordsToDelete will grow too large, up to the point it won't fit on the memory in a single load.


We could just make compacting mandatory, or change the loading method to use some sort of Map. It's a bit of a challange here as the journal needs to keep the adds and update records in order.

> OME on the Journal when processing too many files
> -------------------------------------------------
>
>                 Key: JBMESSAGING-1678
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1678
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2, 2.0.0.beta3
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Set one producer.. sending one message / second (about 200 messages)
> Set another producer/consumer (in another destination) sending as fast as it can. (about 500K messages).
> At the end you will have 200 files... but only 200 messages (one valid on each file).
> This will lead to an OME during reload.
> On trunk, you need to deactivate compacting to replicate this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 17:39:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 7 Jul 2009 17:39:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-96) Extract
	initialization logic
Message-ID: <1674931690.1247002791408.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Extract initialization logic
----------------------------

                 Key: JBBOOT-96
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-96
             Project: JBoss Bootstrap
          Issue Type: Task
          Components: impl-as, impl-base, impl-mc
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 2.0.0-beta-1 


With JBBOOT-95 we now have pre/post states for server initialization.  This means that the initialize() method must be marked final such that its logic containing when to fire the state changes cannot be overridden.  We still need to provide a mechanism for subclasses of AbstractServer to carry out their own initialization logic, so extract this into a "doInitialize()", much like we have a "doStart()".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 17:52:52 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 7 Jul 2009 17:52:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-98) Update the full
 dependency chain to 2.0.0-beta-X level
Message-ID: <1900220212.1247003572283.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Update the full dependency chain to 2.0.0-beta-X level
------------------------------------------------------

                 Key: JBBOOT-98
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-98
             Project: JBoss Bootstrap
          Issue Type: Task
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 2.0.0-beta-1 


All subprojects must go to 2.0.0-beta-X before the beta releases are done (in order)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 17:52:52 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 7 Jul 2009 17:52:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-97) Initialize VFS
 during server initialization
Message-ID: <447861720.1247003572218.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Initialize VFS during server initialization
-------------------------------------------

                 Key: JBBOOT-97
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-97
             Project: JBoss Bootstrap
          Issue Type: Task
          Components: impl-as
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 2.0.0-beta-1 


Use the new LifecycleStates defined by JBBOOT-95 to init VFS during server initialization

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 18:00:52 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 7 Jul 2009 18:00:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1678) OME on the
 Journal when processing too many files
In-Reply-To: <2117713915.1246981551955.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1379357988.1247004052007.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475302#action_12475302 ] 

Tim Fox commented on JBMESSAGING-1678:
--------------------------------------

If you want an ordered map there's always LinkedHashMap.

> OME on the Journal when processing too many files
> -------------------------------------------------
>
>                 Key: JBMESSAGING-1678
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1678
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2, 2.0.0.beta3
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Set one producer.. sending one message / second (about 200 messages)
> Set another producer/consumer (in another destination) sending as fast as it can. (about 500K messages).
> At the end you will have 200 files... but only 200 messages (one valid on each file).
> This will lead to an OME during reload.
> On trunk, you need to deactivate compacting to replicate this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 18:10:51 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 7 Jul 2009 18:10:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-97) Initialize VFS
 during server initialization
In-Reply-To: <447861720.1247003572218.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <509733698.1247004651625.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-97.
---------------------------------------

    Resolution: Done


Resolving, but we won't see the effect here until JBBOOT-96 is done.

> Initialize VFS during server initialization
> -------------------------------------------
>
>                 Key: JBBOOT-97
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-97
>             Project: JBoss Bootstrap
>          Issue Type: Task
>          Components: impl-as
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 2.0.0-beta-1 
>
>
> Use the new LifecycleStates defined by JBBOOT-95 to init VFS during server initialization

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 18:12:51 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Jul 2009 18:12:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1678) OME on the
 Journal when processing too many files
In-Reply-To: <2117713915.1246981551955.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <19811250.1247004771512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475306#action_12475306 ] 

Clebert Suconic commented on JBMESSAGING-1678:
----------------------------------------------

That's not what I meant.

As far as I'm in concern, the updates needs to be in order...


if you did

Add,1
Add2,
Update1
Update2


I need to load them at the same order. as the Update could be a transfer to a DLQ, redelivery.. etc. 


If I used some ordered map, the result at the end would be:

Add1, 
Update1
Add2, 
Update2




Unless you tell me this would be ok.

> OME on the Journal when processing too many files
> -------------------------------------------------
>
>                 Key: JBMESSAGING-1678
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1678
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2, 2.0.0.beta3
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Set one producer.. sending one message / second (about 200 messages)
> Set another producer/consumer (in another destination) sending as fast as it can. (about 500K messages).
> At the end you will have 200 files... but only 200 messages (one valid on each file).
> This will lead to an OME during reload.
> On trunk, you need to deactivate compacting to replicate this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 18:37:52 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Jul 2009 18:37:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1678) OME on the
 Journal when processing too many files
In-Reply-To: <2117713915.1246981551955.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1725265961.1247006272118.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1678:
-----------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=158140


> OME on the Journal when processing too many files
> -------------------------------------------------
>
>                 Key: JBMESSAGING-1678
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1678
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2, 2.0.0.beta3
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Set one producer.. sending one message / second (about 200 messages)
> Set another producer/consumer (in another destination) sending as fast as it can. (about 500K messages).
> At the end you will have 200 files... but only 200 messages (one valid on each file).
> This will lead to an OME during reload.
> On trunk, you need to deactivate compacting to replicate this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 19:04:03 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 7 Jul 2009 19:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7052) when invoked from
 remote client, 
 call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1557473021.1247007843593.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-7052.
---------------------------------

    Resolution: Done


I have created a jboss-profileservice-client.jar artifact that I can use to get past any profileservice related errors. This requires the addition of the following org.jboss.jbossas:jboss-as-profileservice:client dependency:

[524][valkyrie: jbas5-plugin-descriptor-gen]$ svn diff pom.xml 
Index: pom.xml
===================================================================
--- pom.xml	(revision 879)
+++ pom.xml	(working copy)
@@ -193,6 +193,13 @@
             <classifier>client</classifier>
             <scope>runtime</scope>
         </dependency>
+        <dependency>
+            <groupId>org.jboss.jbossas</groupId>
+            <artifactId>jboss-as-profileservice</artifactId>
+            <classifier>client</classifier>
+            <scope>runtime</scope>
+            <version>5.1.0-SNAPSHOT</version>
+        </dependency>
 
         <dependency>
           <groupId>org.jboss</groupId>
[525][valkyrie: jbas5-plugin-descriptor-gen]$



> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 19:33:51 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 7 Jul 2009 19:33:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1678) OME on the
 Journal when processing too many files
In-Reply-To: <2117713915.1246981551955.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <456793071.1247009631437.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1678.
----------------------------------------

    Resolution: Done


I have committed a fix, and added a stress test to validate this issue.

I didn't want to change any ordering on the journal, so I added a cleanup on every X records as discussed on the forums. 

We will revisit this issue if this is not acceptable.

> OME on the Journal when processing too many files
> -------------------------------------------------
>
>                 Key: JBMESSAGING-1678
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1678
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1, 2.0.0.beta2, 2.0.0.beta3
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Set one producer.. sending one message / second (about 200 messages)
> Set another producer/consumer (in another destination) sending as fast as it can. (about 500K messages).
> At the end you will have 200 files... but only 200 messages (one valid on each file).
> This will lead to an OME during reload.
> On trunk, you need to deactivate compacting to replicate this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 19:46:51 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 7 Jul 2009 19:46:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-1140) Bisocket client
 cannot detect connection failure
Message-ID: <2071003850.1247010411469.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Bisocket client cannot detect connection failure
------------------------------------------------

                 Key: JBREM-1140
                 URL: https://jira.jboss.org/jira/browse/JBREM-1140
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: transport
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 2.2.3.SP1


The BisocketClientInvoker never reads from the control socket.  Therefore, it might take a long time for it to notice that the control connection dies, causing confusion between the client and server (for example, the client may reuse a listener ID that the server considers extinct).  By adding a ping reply mechanism, the client must both send and receive a ping for the connection to be known "good", which should help speed up the dead connection detection process.

Since this change is protocol-incompatible, it should be enabled by a configuration option.  I'm using Bisocket.ENABLE_PING_REPLY = "enablePingReply" for this purpose.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 20:12:51 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 7 Jul 2009 20:12:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-1140) Bisocket client
 cannot detect connection failure
In-Reply-To: <2071003850.1247010411469.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <12853602.1247011971511.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBREM-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475331#action_12475331 ] 

David Lloyd commented on JBREM-1140:
------------------------------------

The correct name of the option is "enablePingReplies", plural.

> Bisocket client cannot detect connection failure
> ------------------------------------------------
>
>                 Key: JBREM-1140
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1140
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: transport
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 2.2.3.SP1
>
>
> The BisocketClientInvoker never reads from the control socket.  Therefore, it might take a long time for it to notice that the control connection dies, causing confusion between the client and server (for example, the client may reuse a listener ID that the server considers extinct).  By adding a ping reply mechanism, the client must both send and receive a ping for the connection to be known "good", which should help speed up the dead connection detection process.
> Since this change is protocol-incompatible, it should be enabled by a configuration option.  I'm using Bisocket.ENABLE_PING_REPLY = "enablePingReply" for this purpose.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 21:45:51 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 7 Jul 2009 21:45:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
In-Reply-To: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <467680049.1247017551672.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-7051.
---------------------------------

    Resolution: Done


There can only be one underlying msg provider in jbossas5, so there would not be two different destination managed objects. We have org.jboss.mq.server.jmx.* wrapper classes that are exposing the legacy destinations classes and managed objects. I have updated the MODefintion mappings in the messaging-definitions-jboss-beans.xml deployment to map these legacy classes onto the same MO as the current jms destinations.


> ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7051
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ejb3-tutorial-mdb.jar
>
>
> This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:
> 1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.
> 2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:
> container=JBossMQ|JBossMessaging
> which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.
> Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:
> 15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
> ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
> rvice=Queue, parent=JBoss EAP 5 (default)]
> org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
>         at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
>         at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
> rceManager.java:235)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
> figurationUIBean.java:144)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.seam.util.Reflections.invoke(Reflections.java:22)
>         at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
>         at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
> tion(ResourceConfigurationUIBean_$$_javassist_12.java)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
>         at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
>         at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
>         at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
>         at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
>         at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
>         at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
>         at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
>         at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
>         at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
>         at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>         at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>         at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
>         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:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
> a:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
> :70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
> operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
> a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
> ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
> ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
>         ... 84 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul  7 23:17:51 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 7 Jul 2009 23:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1644) Work out a
 suitable way to provide JBM examples/doc for AS 5
In-Reply-To: <25933843.1244563136418.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <644754300.1247023071478.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1644.
-----------------------------------

    Resolution: Done


done

> Work out a suitable way to provide JBM examples/doc for AS 5
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1644
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1644
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: AS Integration
>    Affects Versions: 1.4.3.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>            Priority: Critical
>             Fix For: 1.4.5.GA
>
>
> Current AS 5 distribution kit doesn't have JBM doc/examples of the corresponding version included, that makes it very inconvenient to use JBM with AS5. Users often get confused with which version of JBM is the correct version, and where to get the resouces (docs, examples).
> We have to provide a solution to that. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 01:51:08 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 8 Jul 2009 01:51:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1680) Improving the
 startup of Messaging Post Office service
Message-ID: <443833333.1247032268842.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Improving the startup of Messaging Post Office service
------------------------------------------------------

                 Key: JBMESSAGING-1680
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1680
             Project: JBoss Messaging
          Issue Type: Feature Request
          Components: JMS Clustering
    Affects Versions: 1.4.4.GA, 1.4.0.SP3.CP08
            Reporter: Howard Gao
            Assignee: Howard Gao
             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA


Investigating the possibility of starting the two JGroups channels concurrently so that the startup process will be faster.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 04:19:51 2009
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Wed, 8 Jul 2009 04:19:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7029) Test
 org.jboss.test.profileservice.test.PlatformMBeanUnitTestCase(profileservice).testThreadMXBean
 fails on JDK6
In-Reply-To: <9161934.1245234836800.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <849784752.1247041191722.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved JBAS-7029.
---------------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
       Resolution: Done


> Test org.jboss.test.profileservice.test.PlatformMBeanUnitTestCase(profileservice).testThreadMXBean fails on JDK6
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7029
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7029
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows and Linux 
> JDK6
>            Reporter: Pavel Slavicek
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Test org.jboss.test.profileservice.test.PlatformMBeanUnitTestCase(profileservice).testThreadMXBean fails on JDK6 on line 
>       Set<ManagedOperation> ops = mo.getOperations();
>       log.debug(ops);
>       assertEquals("Ops count is 8", 8, ops.size());
> JDK6 contains JMX 1.4 and ThreadMXBean has 11 operations.
> Test log:
> junit.framework.AssertionFailedError: Ops count is 8 expected:&lt;8&gt; but was:&lt;11&gt;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 04:47:03 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 8 Jul 2009 04:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1617) JBM does not
 handle
 java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes()
 when copying a foreign message.
In-Reply-To: <23221030.1241532484153.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <419731774.1247042823446.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1617.
-----------------------------------



introduced a system property 'support.bytesId'. If set to false, JBossMessage will not use the bytes ID of the foreign message. Otherwise it stays as before. Document 2.3.1 has added for this.

> JBM does not handle java.lang.UnsupportedOperationException thrown from getCorrelationIDBytes() when copying a foreign message.
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1617
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1617
>             Project: JBoss Messaging
>          Issue Type: Support Patch
>          Components: JMS Facade, Messaging Core
>    Affects Versions: 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.1.beta1, 1.4.1.CR1, 2.0.0 Alpha, 1.4.1.GA, 1.4.2.GA, 1.4.2.GA.SP1, 1.4.3.GA
>         Environment: - Linux 2.6.27-11-generic x86_64
> - Linux 2.6.9-78.EL x86_64
>            Reporter: Alexandre MOOTASSEM
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Some providers can throw UnsupportedOperationException from getCorrelationIDBytes(). This is called in the foreign message constructor of a JBM message. Currently JBM will fail to copy the message since the exception is not handled.
> JavaTM Message Service Specification Version 1.1 :
> " 3.4.5 JMSCorrelationID
> A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.
> JMSCorrelationID can hold one of the following:
> ? A provider-specific message ID
> ? An application-specific String
> ? A provider-native byte[] value
> Since each message sent by a JMS provider is assigned a message ID value, it is convenient to link messages via message ID. All message ID values must start with the 'ID:' prefix.
> In some cases, an application (made up of several clients) needs to use an application-specific value for linking messages. For instance, an application may use JMSCorrelationID to hold a value referencing some external information. Application-specified values must not start with the 'ID:' prefix; this is reserved for provider-generated message ID values.
> If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[] values*. The use of a byte[] value for JMSCorrelationID is non-portable.
> * Their implementation of setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException"
> So, the following constructor should rely on the application-specific String as JMSCorrelationID and handle UnsupportedOperationException :
> /**
>     * A copy constructor for non-JBoss Messaging JMS messages.
>     */   
>    public JBossMessage(Message foreign, long messageID) throws JMSException
>    {
>       super(messageID);
>       setJMSTimestamp(foreign.getJMSTimestamp());
>       try
>       {
>          byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
>          setJMSCorrelationIDAsBytes(corrIDBytes);
>       }
>       catch(JMSException e)
>       {
>          // specified as String
>          String corrIDString = foreign.getJMSCorrelationID();
>          if (corrIDString != null)
>          {
>             setJMSCorrelationID(corrIDString);
>          }
>       }
>       
>       setJMSReplyTo(foreign.getJMSReplyTo());
>       setJMSDestination(foreign.getJMSDestination());
>       setJMSDeliveryMode(foreign.getJMSDeliveryMode());
>       setJMSExpiration(foreign.getJMSExpiration());
>       setJMSPriority(foreign.getJMSPriority());
>       setJMSType(foreign.getJMSType());
>       for (Enumeration props = foreign.getPropertyNames(); props.hasMoreElements(); )
>       {
>          String name = (String)props.nextElement();
>          
>          Object prop = foreign.getObjectProperty(name);
>          this.setObjectProperty(name, prop);                       
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Wed Jul  8 05:14:51 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 8 Jul 2009 05:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1667) MBeans
 cannot have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1472323869.1247044491449.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475374#action_12475374 ] 

Howard Gao commented on JBMESSAGING-1667:
-----------------------------------------

We can check the name in DestinationServiceSupport.startService(), if it contains forward slash, throw an exception, that make the deployment fail.

         if (name.contains("/"))
         {
            throw new IllegalStateException("The " + (isQueue() ? "queue" : "topic") +
                                            " " +
                                            "name should not contain forward slash " + name);
         }


> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 07:45:51 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Wed, 8 Jul 2009 07:45:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1679) Could not
 find reference with id
In-Reply-To: <318505980.1246983291590.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1055797765.1247053551532.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor reassigned JBMESSAGING-1679:
----------------------------------------

    Assignee: Andy Taylor  (was: Tim Fox)


> Could not find reference with id
> --------------------------------
>
>                 Key: JBMESSAGING-1679
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1679
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>            Reporter: Adrian Woodhead
>            Assignee: Andy Taylor
>
> Refer to http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242246#4242246 for more information, stack trace etc.
> In essence the problem seems to be messages with an expiry time set seem to have problems when pre-ack mode is used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 08:32:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 8 Jul 2009 08:32:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-206) Performance work
In-Reply-To: <12602944.1244644796627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <97337339.1247056371576.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBXB-206:
---------------------------------

    Attachment: jbossxb-2.zip


> Performance work
> ----------------
>
>                 Key: JBXB-206
>                 URL: https://jira.jboss.org/jira/browse/JBXB-206
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Jesper Pedersen
>            Assignee: Alexey Loubyansky
>         Attachments: jboss-profiler.properties, jbossxb-2.zip, jbossxb.zip, server-2.log.gz, server.log.gz
>
>
> I'm seeing some large unmarshall times when using JBossXB to retrieve my JBMETA model.
> Created this issue in order to track any performance improvements that can be done.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 09:44:05 2009
From: jira-events at lists.jboss.org (Alan Gairey (JIRA))
Date: Wed, 8 Jul 2009 09:44:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2199)
 NullPointerException with JPA session persistence in Drools Flow
Message-ID: <233050457.1247060645508.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

NullPointerException with JPA session persistence in Drools Flow
----------------------------------------------------------------

                 Key: JBRULES-2199
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2199
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core (flow)
    Affects Versions: 5.0.1.FINAL
            Reporter: Alan Gairey
            Assignee: Mark Proctor


I'm currently using Drools Flow with JPA session persistence enabled as described in section 5.1 of the User Guide.
As a process executes, session information is saved to the H2 database correctly.

The problem comes when recreating a session from its persisted state, using the code:

{code}
// recreate the session from database using the sessionId
ksession = JPAKnowledgeService.loadStatefulKnowledgeSession( sessionId, kbase, null, env );
{code}

This gives me a NullPointerException.

Having looked into the Drools Flow source code, I think the problem is in the class drools-persistence-jpa\src\main\java\org\drools\persistence\session\SingleSessionCommandService.java.

The 4th constructor of this class (starting line 132) is called as part of the loading of a knowledge session from the H2 database (i.e. via the code above); this in turn leads to the afterCompletion method of the inner class SynchronizationImpl being called. The final two lines of this method are:

{code}
((JPAProcessInstanceManager) ((ReteooWorkingMemory) session).getProcessInstanceManager()).clearProcessInstances();
((JPAWorkItemManager) ((ReteooWorkingMemory) session).getWorkItemManager()).clearWorkItems();
{code}

However, when called via the route described above, the session member variable of SingleSessionCommandService has not been set, thus causing the NullPointerException.

(Interestingly, running the unit tests for drools-persistence-jpa does result in a NullPointerException being thrown multiple times, although the tests are still listed as having passed.)

I believe enclosing the above two lines as follows will fix the problem:

{code}
if (session != null) { 
    ((JPAProcessInstanceManager) ((ReteooWorkingMemory) session).getProcessInstanceManager()).clearProcessInstances(); 
    ((JPAWorkItemManager) ((ReteooWorkingMemory) session).getWorkItemManager()).clearWorkItems(); 
} 
{code}

Also, in the 4th constructor of SingleSessionCommandService, after the session has been set, the following line needs to be added to ensure the session id is the same as the session info id:

{code}
((ReteooStatefulSession) this.session).setId( this.sessionInfo.getId() );
{code}

(This line _is_ present at the end of the 3rd constructor - line 123.)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 10:28:51 2009
From: jira-events at lists.jboss.org (Andre Malenfant (JIRA))
Date: Wed, 8 Jul 2009 10:28:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2200) Add the ablility
 to add an excel decision table and drl template in a changeset
Message-ID: <9653463.1247063331424.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add the ablility to add an excel decision table and drl template in a changeset
-------------------------------------------------------------------------------

                 Key: JBRULES-2200
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2200
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-compiler, drools-decisiontables
            Reporter: Andre Malenfant
            Assignee: Mark Proctor


Currently, change sets can contain Excel decision tables that will be automatically compiled. This allows to use the Agent functionality to have the decision table automatically recompiled upon a change to the Excel file. This only works for decision tables that contain the necessary metadata to generate the rules but does not work for "plain" decision tables that are compiled programatically by providing a template drl and using an ExternalSpreadsheetCompiler.

It would be very useful to be able to specify a decision table and the corresponding drl template in a change set and be able to use the Agent functionality to have the rules recompiled automatically when one or the other file changes.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 10:43:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 8 Jul 2009 10:43:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7084) Add support for a
 traditional XA strategy in the JMS resource adapter
Message-ID: <953042023.1247064231431.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add support for a traditional XA strategy in the JMS resource adapter
---------------------------------------------------------------------

                 Key: JBAS-7084
                 URL: https://jira.jboss.org/jira/browse/JBAS-7084
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JCA service
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


Add support for a traditional (JCA 1.5 Chapter 12.5.6 Option A) XA transaction model in the generic JMS resource adapter.

The default when using an XASession should be the traditional one, but the old behavior can be enabled by setting the ForceTransacted flag in the activation spec.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 10:45:51 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 8 Jul 2009 10:45:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <1353402761.1247064351886.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475449#action_12475449 ] 

Stan Silvert commented on JBAS-7032:
------------------------------------

I think I see what the problem is. So after you get rid of the NPE by moving the jars, you try to hit the admin console and see the stack trace reported earlier.

I notice that this stack trace contains WebBeansPhaseListener. This is installed automatically by JSF when it sees the /webbeans.deployer/lib-int/faces in the classpath. /webbeans.deployer/lib-int/faces/META-INF/faces-config.xml has an entry that tells JSF to load the WebBeansPhaseListener.

Since admin console doesn't use WebBeans, this should not happen. So I suspect that the problem is with the WebBeans deployer. I'm guessing that it is placing the /webbeans.deployer/lib-int/faces in some classpath that is visible by the admin console's ServletContext resource path.

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 11:16:51 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 8 Jul 2009 11:16:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-212)
 SchemaBindingValidator should pass
 default schema resolver in case SchemaBinding doesn't have one
Message-ID: <1096870749.1247066211458.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SchemaBindingValidator should pass default schema resolver in case SchemaBinding doesn't have one
-------------------------------------------------------------------------------------------------

                 Key: JBXB-212
                 URL: https://jira.jboss.org/jira/browse/JBXB-212
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.2.Beta1
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: JBossXB-2.0.2.GA


The following method

public void validate(InputSource is, SchemaBinding binding)

will use binding.getSchemaResolver() to load schemas referenced from the main XSD. If the binding is not associated with a SchemaBindingResolver then the default resolver should be used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 11:36:51 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 8 Jul 2009 11:36:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-212) SchemaBindingValidator
 should pass
 default schema resolver in case SchemaBinding doesn't have one
In-Reply-To: <1096870749.1247066211458.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1338850780.1247067411450.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBXB-212.
----------------------------------

    Resolution: Done


Fixed. SchemaBindingValidator now has a property schemaResolver which can be initialized with constructor or the setter.

> SchemaBindingValidator should pass default schema resolver in case SchemaBinding doesn't have one
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBXB-212
>                 URL: https://jira.jboss.org/jira/browse/JBXB-212
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.2.Beta1
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossXB-2.0.2.GA
>
>
> The following method
> public void validate(InputSource is, SchemaBinding binding)
> will use binding.getSchemaResolver() to load schemas referenced from the main XSD. If the binding is not associated with a SchemaBindingResolver then the default resolver should be used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 11:38:51 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 8 Jul 2009 11:38:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBXB-212)
 SchemaBindingValidator should
 pass default schema resolver in case SchemaBinding doesn't have one
In-Reply-To: <1096870749.1247066211458.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <723508262.1247067531513.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBXB-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475459#action_12475459 ] 

Alexey Loubyansky commented on JBXB-212:
----------------------------------------

Also, AbstractMutableSchemaResolver when creating an instance of SchemaBindingValidator will initialize its schemaResolver to itself.

> SchemaBindingValidator should pass default schema resolver in case SchemaBinding doesn't have one
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBXB-212
>                 URL: https://jira.jboss.org/jira/browse/JBXB-212
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.2.Beta1
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossXB-2.0.2.GA
>
>
> The following method
> public void validate(InputSource is, SchemaBinding binding)
> will use binding.getSchemaResolver() to load schemas referenced from the main XSD. If the binding is not associated with a SchemaBindingResolver then the default resolver should be used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 11:52:52 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 8 Jul 2009 11:52:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-7052) when invoked from
 remote client, 
 call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1322152111.1247068372218.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer reopened JBAS-7052:
--------------------------------



> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 11:52:51 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 8 Jul 2009 11:52:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7052) when invoked from
 remote
 client, call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <180217318.1247068371902.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475460#action_12475460 ] 

Ian Springer commented on JBAS-7052:
------------------------------------

I updated the pom.xml for https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/  to contain a dep on the new client jar, but it still fails with:

Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
        at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
        at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:247)
        at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
        at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
        at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at java.util.HashSet.readObject(HashSet.java:291)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at java.util.HashSet.readObject(HashSet.java:291)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
        at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
        at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
        at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

So it's still looking for org.jboss.profileservice.management.ManagedOperationDelegate, even though it looks like the class's package was changed to org.jboss.profileservice.management.client in the new client jar...


> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 11:54:51 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 8 Jul 2009 11:54:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7052) when invoked from
 remote
 client, call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1563441289.1247068491636.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475461#action_12475461 ] 

Ian Springer commented on JBAS-7052:
------------------------------------

Scott, it looks like you only made this fix in the Branch_5_x branch. I'm using the EAP5 branch. Can you make the change in that branch too?


> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 12:13:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 8 Jul 2009 12:13:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7084) Add support for a
 traditional XA strategy in the JMS resource adapter
In-Reply-To: <953042023.1247064231431.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1784671742.1247069631458.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBAS-7084.
-----------------------------------

    Resolution: Done


> Add support for a traditional XA strategy in the JMS resource adapter
> ---------------------------------------------------------------------
>
>                 Key: JBAS-7084
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7084
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Add support for a traditional (JCA 1.5 Chapter 12.5.6 Option A) XA transaction model in the generic JMS resource adapter.
> The default when using an XASession should be the traditional one, but the old behavior can be enabled by setting the ForceTransacted flag in the activation spec.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 12:58:51 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Wed, 8 Jul 2009 12:58:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6936) Testsuite fails
 during
 tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
In-Reply-To: <368622.1242662765255.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <595339338.1247072331703.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-6936:
---------------------------------

    Labels: profileservice  (was: )


> Testsuite fails during tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6936
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6936
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>
> The AS fails to start for the second time during the tests-profileservice target of the testsuite. This is caused by the first instance not being properly shutdown by the following ant command: <server:stop name="profileservice"/>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 13:00:51 2009
From: jira-events at lists.jboss.org (Konstantin Pupkov (JIRA))
Date: Wed, 8 Jul 2009 13:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
Message-ID: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

fetch based on messageId doesn't work
-------------------------------------

                 Key: JBMESSAGING-1681
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.3.GA
         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
            Reporter: Konstantin Pupkov
            Assignee: Tim Fox


here is me code on client:
String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
Message msg1= recv.receive();---->hungs on forever


I tied
QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well


Please fix it and keep standard approach: JMSMessageID not JBMessageID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 13:04:51 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 8 Jul 2009 13:04:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1361171846.1247072691678.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow reassigned JBAS-6185:
----------------------------------

    Assignee: Scott Marlow  (was: Shelly McGowan)


> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Scott Marlow
>            Priority: Blocker
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 13:09:51 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Jul 2009 13:09:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <426577827.1247072991527.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475470#action_12475470 ] 

Tim Fox commented on JBMESSAGING-1681:
--------------------------------------

Konstantin - if you're using the JMS API, then you should be using JMSMessageID, not JBMessageID, as per JMS spec.

Can you tell me where in the docs does it say to use JBMessageID?

Also can you please post a full test program that demonstrates the issue. Your code snippet does not go into enough detail.

> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Tim Fox
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 13:14:51 2009
From: jira-events at lists.jboss.org (asookazian (JIRA))
Date: Wed, 8 Jul 2009 13:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6549) Investigate
 increased memory requirements and deployment time
In-Reply-To: <5128231.1235670884495.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1105758036.1247073291772.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475471#action_12475471 ] 

asookazian commented on JBAS-6549:
----------------------------------

Why do these problems show up in GA versions and not before?  All JBoss has to do is load test a few apps and analyze results, no?

> Investigate increased memory requirements and deployment time
> -------------------------------------------------------------
>
>                 Key: JBAS-6549
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6549
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.0.GA, JBossAS-5.0.1.GA
>            Reporter: Dimitris Andreadis
>            Assignee: Ales Justin
>         Attachments: AS 5_x profiler snapshot.zip
>
>
> A user reported x2 increase in deployment time and x4 increase in memory usage when moving an application from JBoss 4.2 -> 5.x.
> We need to investigate how to improve both the memory usage and the deployment time.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 13:57:51 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 8 Jul 2009 13:57:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7052) when invoked from
 remote
 client, call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1038402196.1247075871655.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475482#action_12475482 ] 

Ian Springer commented on JBAS-7052:
------------------------------------

I got further after I updated my server to the latest bits, in addition to my client. However, now I get a CNFE for ManagedPropertyDelegate...

C:\Projects\jopr-trunk\modules\tools\jbas5-plugin-descriptor-gen\target>java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedPropertyDelegate
        at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
        at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:247)
        at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
        at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
        at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at java.util.HashMap.readObject(HashMap.java:1030)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at java.util.HashSet.readObject(HashSet.java:291)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
        at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
        at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
        at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
        at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
        at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
        at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)


> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 14:23:52 2009
From: jira-events at lists.jboss.org (Konstantin Pupkov (JIRA))
Date: Wed, 8 Jul 2009 14:23:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2020183138.1247077432338.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475492#action_12475492 ] 

Konstantin Pupkov commented on JBMESSAGING-1681:
------------------------------------------------

You didn't get my complain.
I tried JMSMessageID as well - it doesn't work. It works fine with JBOSS 4.1.GA.
I tried to find workaround that is why I tried "JBMessageID" in my sample.

here is link to JBMessageID:
JavaDoc class:
org.jboss.messaging.core.filter.impl.FilterImpl

public class FilterImpl
extends java.lang.Object
implements Filter

This class implements a JBoss Messaging filter

Version:
    $Revision: 3569 $ $Id: Selector.java 3569 2008-01-15 21:14:04Z timfox $
Author:
    Tim Fox, Jeff Mesnil JBM filters have the same syntax as JMS 1.1 selectors, but the identifiers are different. Valid identifiers that can be used are: *******!!!!!!!JBMessageID!!!!!!!!******** - the message id of the message JBMPriority - the priority of the message JBMTimestamp - the timestamp of the message JBMDurable - "DURABLE" or "NON_DURABLE" JBMExpiration - the expiration of the message JBMSize - the encoded size of the full message in bytes Any other identifers that appear in a filter expression represent header values for the message String values must be set as SimpleString, not java.lang.String (see JBMESSAGING-1307). Derived from JBoss MQ version by, Norbert Lataille, Juha Lindfors, Jason Dillon, Scott Stark, Tim Fox 




> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Tim Fox
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 14:35:51 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 8 Jul 2009 14:35:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-107) SJC: Add support
 for a default value in system properties
In-Reply-To: <803321689.1246904225294.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1833426754.1247078151761.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-107.
-----------------------------------

    Resolution: Done


> SJC: Add support for a default value in system properties
> ---------------------------------------------------------
>
>                 Key: JBJCA-107
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-107
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Core
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Add support for a default in system properties like
>  ${jboss.bind.address:localhost}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 14:39:52 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 8 Jul 2009 14:39:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <460152300.1247078392439.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475505#action_12475505 ] 

Tim Fox commented on JBMESSAGING-1681:
--------------------------------------

Konstantin-

That class FilterImpl is in the *JBM 2.0* code base. According to your report you are using JBM 1.4. JBM 1.4 and JBM 2.0 are pretty much completely different projects/codebases. Moreover that class is a *core filter* - it has nothing to do with JMS, however that's not relevant since you're not using JBM 2.0 anyway.

Regarding using JMSMessageID, we're still waiting for your test program that demonstrates the issue. It should just be a small program with a few lines of JMS code. Once you have provided that someone will investigate it.

> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Tim Fox
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 15:10:52 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 8 Jul 2009 15:10:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-106) SJC: Add support for
 property maps
In-Reply-To: <1148079522.1246903911428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <922163058.1247080252011.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-106:
----------------------------------

    Fix Version/s:     (was: 1.0.0.Alpha2)


> SJC: Add support for property maps
> ----------------------------------
>
>                 Key: JBJCA-106
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-106
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Core
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>
> Add support for property maps, so they can be passed in the configuration.
> The remotable naming server is an example of an use-case.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 15:33:51 2009
From: jira-events at lists.jboss.org (Mr X (JIRA))
Date: Wed, 8 Jul 2009 15:33:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6537) Ant task
 <jmx><setAttribute> problem : unable to use <value> tag inside
In-Reply-To: <2639620.1156486125456.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <59663339.1247081631557.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475515#action_12475515 ] 

Mr X commented on JBAS-6537:
----------------------------

Can anyone suggest a workaround or alternative library to accomplish setting an attribute while we wait for a fix?

> Ant task <jmx><setAttribute> problem : unable to use <value> tag inside
> -----------------------------------------------------------------------
>
>                 Key: JBAS-6537
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6537
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Windows XP, 
> JRE 1.5
> Eclipse 3.2
> Ant 1.6.5
>            Reporter: Benoit Lavenier
>
> The Ant task JMX (org.jboss.ant.JMX) has a code error in the subclass "Setter" (used by <setAttribute> sub task)
> The methode named setValue in Setter subclass should be "addValue"
> Please refer to the folowwing url : http://ant.apache.org/manual/develop.html  , and the "Supporting nested elements" section
> I think the following code will works fine :
>        // "setValue" method (of subclass Setter) remaned in "addValue"
>        public void addValue(Param value)
>        {
>     	   // This will only consider the last <value> tag, if more than one tag 
> 		   this.value = value;
>        }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 16:05:51 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 8 Jul 2009 16:05:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7052) when invoked from
 remote
 client, call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <872657659.1247083551641.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475518#action_12475518 ] 

Scott M Stark commented on JBAS-7052:
-------------------------------------

I have moved the ManagedPropertyDelegate to the client jar and updated the org.jboss.jbossas:jboss-as-profileservice:client snapshot artifact. Both the server and the snapshot need to be updated to validate this.

> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 16:28:51 2009
From: jira-events at lists.jboss.org (Kit Chan (JIRA))
Date: Wed, 8 Jul 2009 16:28:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2201) Rule got executed
 even does not satisfy LHS after firing an external event in Flow
Message-ID: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Rule got executed even does not satisfy LHS after firing an external event in Flow
----------------------------------------------------------------------------------

                 Key: JBRULES-2201
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core  (expert)
    Affects Versions: 5.0.1.FINAL
         Environment: Windows XP SP3, Eclipse 3.4.2
            Reporter: Kit Chan
            Assignee: Mark Proctor


I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 16:36:51 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 8 Jul 2009 16:36:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7085) Replace ejb3 secured
 profile service facade with secured remoting proxy
Message-ID: <1810173299.1247085411421.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Replace ejb3 secured profile service facade with secured remoting proxy
-----------------------------------------------------------------------

                 Key: JBAS-7085
                 URL: https://jira.jboss.org/jira/browse/JBAS-7085
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ProfileService, Security
            Reporter: Scott M Stark
            Assignee: Scott M Stark
             Fix For: JBossAS-5.2.0.Beta1


Its been decided to limit the number of dependencies an admin client needs to communicate with a secured profile service. We need to drop the ejb3 facade and provide a secured remoting based proxy bound in global jndi and an unsecured, but security manager controlled unsecured proxy under the java: local jndi namespace.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 16:38:51 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Wed, 8 Jul 2009 16:38:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7085) Replace ejb3 secured
 profile service facade with secured remoting proxy
In-Reply-To: <1810173299.1247085411421.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1774484964.1247085531489.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark updated JBAS-7085:
--------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242480


> Replace ejb3 secured profile service facade with secured remoting proxy
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7085
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7085
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService, Security
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Its been decided to limit the number of dependencies an admin client needs to communicate with a secured profile service. We need to drop the ejb3 facade and provide a secured remoting based proxy bound in global jndi and an unsecured, but security manager controlled unsecured proxy under the java: local jndi namespace.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 16:53:05 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 8 Jul 2009 16:53:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-108) SJC: Add support for
 <constructor>
In-Reply-To: <962038176.1246904932262.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1990097731.1247086385291.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-108.
-----------------------------------

    Resolution: Done


> SJC: Add support for <constructor>
> ----------------------------------
>
>                 Key: JBJCA-108
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-108
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Core
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Add support for <constructor> constructs for beans. 
> An example
>     <bean name="LookupPool">
>         <constructor factoryMethod="newFixedThreadPool"  factoryClass="java.util.concurrent.Executors">
>             <parameter>2</parameter>
>         </constructor>
>     </bean>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 18:14:51 2009
From: jira-events at lists.jboss.org (Kevin Bates (JIRA))
Date: Wed, 8 Jul 2009 18:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
Message-ID: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Can't enlist in transaction with second Oracle XA connection/resource.
----------------------------------------------------------------------

                 Key: JBAS-7086
                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Transaction Manager (Arjuna)
    Affects Versions: JBossAS-5.0.1.GA
         Environment: The operating system has been windows, but that doesn't appear to be related.
Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
            Reporter: Kevin Bates
            Assignee: Jonathan Halliday


We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.

At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:

2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
oracle.jdbc.xa.OracleXAException
	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
<deleted due to 32K requirement>

2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
<deleted due to 32K requirement>


2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
	at java.lang.reflect.Method.invoke(Method.java:599)
	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
	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:404)
	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
	at org.jboss.ejb.Container.invoke(Container.java:1029)
	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
	at $Proxy134.executeChanges(Unknown Source)
	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
	at java.lang.reflect.Method.invoke(Method.java:599)
	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
	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:378)
	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
	at org.jboss.ejb.Container.invoke(Container.java:1029)
	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
	at $Proxy135.executeChanges(Unknown Source)
	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
	at java.security.AccessController.doPrivileged(AccessController.java:284)
	at javax.security.auth.Subject.doAs(Subject.java:573)
	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
	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:235)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:735)
Caused by: 
org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
	... 90 more
Caused by: 
org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
	... 92 more
Caused by: 
javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
	... 96 more


The two XA data sources are configured as follows:

<datasources>
 <xa-datasource>
      <jndi-name>OraDSXA</jndi-name>
      <use-java-context>false</use-java-context>
		<set-tx-query-timeout/>
      <track-connection-by-tx/>
      <isSameRM-override-value>false</isSameRM-override-value>
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
      <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
      <xa-datasource-property name="User">OS1</xa-datasource-property>
      <xa-datasource-property name="Password">xxxx</xa-datasource-property>
      <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
      <no-tx-separate-pools/>
      <metadata>
      <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
          <type-mapping>Oracle9i</type-mapping>
      </metadata>
  </xa-datasource>
</datasources>

<datasources>
 <xa-datasource>
      <jndi-name>OraGCDDSXA</jndi-name>
      <use-java-context>false</use-java-context>
		<set-tx-query-timeout/>
      <track-connection-by-tx/>
      <isSameRM-override-value>false</isSameRM-override-value>
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
      <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
      <xa-datasource-property name="User">GCD</xa-datasource-property>
      <xa-datasource-property name="Password">xxxx</xa-datasource-property>
      <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
      <no-tx-separate-pools/>
      <metadata>
      <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
          <type-mapping>Oracle9i</type-mapping>
      </metadata>
  </xa-datasource>
</datasources>


We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.

Kind regards.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 19:36:51 2009
From: jira-events at lists.jboss.org (Konstantin Pupkov (JIRA))
Date: Wed, 8 Jul 2009 19:36:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1844137623.1247096211488.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Konstantin Pupkov updated JBMESSAGING-1681:
-------------------------------------------

    Attachment: mdb-with-error.zip


Please take a look on my sample. I rework it based on original mdb sample from ejb3-tutorial

> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Tim Fox
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 22:51:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 8 Jul 2009 22:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1844951510.1247107889768.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1681:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 22:53:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 8 Jul 2009 22:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1666336372.1247108009152.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1681:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 23:19:43 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 8 Jul 2009 23:19:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7087) Remove AS references
 to legacy bootstrap in src/assembly/shutdown.xml
Message-ID: <1433546294.1247109583232.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Remove AS references to legacy bootstrap in src/assembly/shutdown.xml
---------------------------------------------------------------------

                 Key: JBAS-7087
                 URL: https://jira.jboss.org/jira/browse/JBAS-7087
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Build System
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: JBossAS-5.0.2.GA, JBossAS-6.0.0.Alpha1


After the bootstrap projects went to 2.0.0-X, this was left in the wake.  Clean up.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 23:32:29 2009
From: jira-events at lists.jboss.org (Masao Kato (JIRA))
Date: Wed, 8 Jul 2009 23:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1682) duplicate key
 value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
Message-ID: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
---------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1682
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Clustering
    Affects Versions: 1.4.0.SP3.CP07
            Reporter: Masao Kato
            Assignee: Tim Fox



NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 

When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 23:34:29 2009
From: jira-events at lists.jboss.org (Masao Kato (JIRA))
Date: Wed, 8 Jul 2009 23:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1347189770.1247110469915.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475545#action_12475545 ] 

Masao Kato commented on JBMESSAGING-1682:
-----------------------------------------

Generated log:

2009-07-07 14:05:27,300 WARN  [org.jboss.messaging.core.impl.JDBCSupport] SQLException caught, SQLState 23505 code:0- assuming deadlock detected, try:1
org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "jbm_msg_pkey"
	at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1608)
	at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1343)
	at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:194)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:451)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:350)
	at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:304)
	at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:278)
	at org.jboss.messaging.core.impl.JDBCPersistenceManager$1AddReferenceRunner.doTransaction(JDBCPersistenceManager.java:1357)
	at org.jboss.messaging.core.impl.JDBCSupport$JDBCTxRunner2.execute(JDBCSupport.java:474)
	at org.jboss.messaging.core.impl.JDBCSupport$JDBCTxRunner2.executeWithRetry(JDBCSupport.java:512)
	at org.jboss.messaging.core.impl.JDBCPersistenceManager.addReference(JDBCPersistenceManager.java:1408)
	at org.jboss.messaging.core.impl.ChannelSupport.handle(ChannelSupport.java:227)
	at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.routeInternal(MessagingPostOffice.java:2212)
	at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.route(MessagingPostOffice.java:499)
	at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:755)
	at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:399)
	at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:87)
	at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_7280680627620114891.invokeNext(SessionAdvised$send_7280680627620114891.java)
	at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:157)
	at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121)
	at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_7280680627620114891.invokeNext(SessionAdvised$send_7280680627620114891.java)
	at org.jboss.jms.server.endpoint.advised.SessionAdvised.send(SessionAdvised.java)
	at org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(SessionSendRequest.java:95)
	at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:866)
	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:608)
	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:420)
	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:173)
2009-07-07 14:05:27,301 WARN  [org.jboss.messaging.core.impl.JDBCSupport] Trying again after a pause


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Masao Kato
>            Assignee: Tim Fox
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 23:34:30 2009
From: jira-events at lists.jboss.org (Masao Kato (JIRA))
Date: Wed, 8 Jul 2009 23:34:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <134979799.1247110470357.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475546#action_12475546 ] 

Masao Kato commented on JBMESSAGING-1682:
-----------------------------------------

A source code to seem to be a problem

org.jboss.messaging.core.impl.RotatingID.java
   public synchronized long getID()
   {
      long id1 = nodeID << 54;

      long id2 = System.currentTimeMillis() << 14;

      long id = id1 | id2 | count;

      if (count == Short.MAX_VALUE)
      {
         count = 0;

         long now = System.currentTimeMillis();

         //Safety - not likely to happen

         while (now == lastTime)
         {
            try
            {
               Thread.sleep(1);
            }
            catch (InterruptedException e)
            {}

            now = System.currentTimeMillis();
         }

         lastTime = now;
      }
      else
      {
         count++;
      }

      return id;
   }


I think that the position of the shift of the bit is strange. 
I understand that the same message ID is generated with the same count value at the same time when I carry out the following message ID generation sample programs.

public class MsgIDTest {

	public static void main(String[] args) {
		

	      long tmptime = System.currentTimeMillis();

	      for (long i = 0; i <255; i++) {
		      printId(i,tmptime,(short)(Short.MAX_VALUE-1));
			
	      }
	      

	}

	
	static public void printId(long nodeID, long time, short count) {
		

        System.out.println("    nodeID:" + Long.toString(nodeID));
		System.out.println("        ms:" + Long.toBinaryString(time));

		//generate id
		long id1 = nodeID << 54;

		long id2 = time << 14;

		long id = id1 | id2 | count;

		System.out.println("     MsgID:" + Long.toString(id));

		System.out.println("==Binary=");

		System.out.println("    nodeID:" + Long.toBinaryString(nodeID));
		System.out.println("nodeID<<54:" + Long.toBinaryString(id1));
		System.out.println("    ms<<14:" + Long.toBinaryString(id2));
		System.out.println("     MsgID:" + Long.toBinaryString(id));
		System.out.println("");

	}
	
	
}

output:
    nodeID:0
        ms:10010001001011101100010000101011011100010
     MsgID:20432645850169344
==Binary=
    nodeID:0
nodeID<<54:0
    ms<<14:1001000100101110110001000010101101110001000000000000000
     MsgID:1001000100101110110001000010101101110001000000000000000

    nodeID:1
        ms:10010001001011101100010000101011011100010
     MsgID:20432645850169344
==Binary=
    nodeID:1
nodeID<<54:1000000000000000000000000000000000000000000000000000000
    ms<<14:1001000100101110110001000010101101110001000000000000000
     MsgID:1001000100101110110001000010101101110001000000000000000

    nodeID:2
        ms:10010001001011101100010000101011011100010
     MsgID:56461442869133312
==Binary=
    nodeID:10
nodeID<<54:10000000000000000000000000000000000000000000000000000000
    ms<<14:1001000100101110110001000010101101110001000000000000000
     MsgID:11001000100101110110001000010101101110001000000000000000

    nodeID:3
        ms:10010001001011101100010000101011011100010
     MsgID:56461442869133312
==Binary=
    nodeID:11
nodeID<<54:11000000000000000000000000000000000000000000000000000000
    ms<<14:1001000100101110110001000010101101110001000000000000000
     MsgID:11001000100101110110001000010101101110001000000000000000


Workaround:
Don't use an ID number next to each other node ID in the cluster.


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Masao Kato
>            Assignee: Tim Fox
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 23:41:41 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Wed, 8 Jul 2009 23:41:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-96) Extract
	initialization logic
In-Reply-To: <1674931690.1247002791408.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1461691749.1247110901848.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-96.
---------------------------------------

    Resolution: Done


> Extract initialization logic
> ----------------------------
>
>                 Key: JBBOOT-96
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-96
>             Project: JBoss Bootstrap
>          Issue Type: Task
>          Components: impl-as, impl-base, impl-mc
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 2.0.0-beta-1 
>
>
> With JBBOOT-95 we now have pre/post states for server initialization.  This means that the initialize() method must be marked final such that its logic containing when to fire the state changes cannot be overridden.  We still need to provide a mechanism for subclasses of AbstractServer to carry out their own initialization logic, so extract this into a "doInitialize()", much like we have a "doStart()".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 23:51:30 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 8 Jul 2009 23:51:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1821898179.1247111490016.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475547#action_12475547 ] 

Howard Gao commented on JBMESSAGING-1681:
-----------------------------------------

Hi Konstantin,

I know what the problem is - you didn't call connection.start() before you receive the message. If you don't start the connecton, message will never be delivered to the consumer.

So I'm going to reject this jira.

Howard


> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul  8 23:53:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 8 Jul 2009 23:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1681) fetch based on
 messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <257058057.1247111609845.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1681.
-----------------------------------

    Resolution: Rejected


rejected as it's not an issue. 

> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 00:47:40 2009
From: jira-events at lists.jboss.org (Konstantin Pupkov (JIRA))
Date: Thu, 9 Jul 2009 00:47:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <867510109.1247114860623.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475549#action_12475549 ] 

Konstantin Pupkov commented on JBMESSAGING-1681:
------------------------------------------------

Yes. You are correct. Then I added cnn.start(). All things works. But that mean your sample is not correct. Please correct example. As far as I rework your example. ejb3-tutorial.....mdb

> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 02:05:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 02:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1667) MBeans cannot
 have heirarchical names
In-Reply-To: <6684184.1245886918241.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <371258814.1247119529222.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1667.
-----------------------------------

    Resolution: Done


done.

> MBeans cannot have heirarchical names
> -------------------------------------
>
>                 Key: JBMESSAGING-1667
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1667
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>         Environment: JBoss 5.1.0.GA
>            Reporter: Richard Kennard
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In JBoss 4.2.3.GA, it was possible to declare queues with 'heirarchical' names, for example:
> <mbean code="..." name="...,name=app1/emails">
> The forward slash in 'app1/emails' created a nested JNDI context of 'queue/app1/emails'. In JBoss 5.1.0.GA this no longer works. JBoss fails saying that the top-level context 'app1' does not exist. This is true, but JBoss should create it just-in-time.
> A workaround proposed on the forums is to use the 'JNDIName' attribute:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> This works from a JNDI perspective, but the mbean itself is still named just 'emails' leaving the potential for name clashes:
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app1/emails</attribute>
> <mbean code="..." name="...,name=emails">
>    <attribute name="JNDIName">app2/emails</attribute>
> In JBoss 4.2.3.GA it was possible to declare queue names safely nested within their own heirarchies to avoid the possibility of name clashes. It would be nice to have this in JBoss 5.1.0.GA too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 02:28:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 02:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1875422107.1247120909652.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475557#action_12475557 ] 

Howard Gao commented on JBMESSAGING-1681:
-----------------------------------------

Hi can you kindly point me where I can get ejb3-tutorial example and see if it has the problem? Thanks.

Howard


> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 02:58:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 02:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1900495222.1247122709218.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475561#action_12475561 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

Yes, the ID generation algorithm is dubious. The node id field, time field and counter field overlap each other, I believe it is not what it is intended.
It needs to modify the code a bit.
Thanks!


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Masao Kato
>            Assignee: Tim Fox
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 03:00:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 03:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <937024290.1247122829362.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1682:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 04:28:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Jul 2009 04:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <98617087.1247128109230.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475574#action_12475574 ] 

Tim Fox commented on JBMESSAGING-1682:
--------------------------------------

Can you add more info here why you think the algorithm is wrong. I.e. please post the algorithm and explain why it is wrong. I want to know when this was introduced.

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 04:32:29 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Thu, 9 Jul 2009 04:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1679) Could not find
 reference with id
In-Reply-To: <318505980.1246983291590.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1568599893.1247128349434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor closed JBMESSAGING-1679.
------------------------------------

    Resolution: Done


> Could not find reference with id
> --------------------------------
>
>                 Key: JBMESSAGING-1679
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1679
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>            Reporter: Adrian Woodhead
>            Assignee: Andy Taylor
>
> Refer to http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242246#4242246 for more information, stack trace etc.
> In essence the problem seems to be messages with an expiry time set seem to have problems when pre-ack mode is used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 04:32:29 2009
From: jira-events at lists.jboss.org (Jonathan Halliday (JIRA))
Date: Thu, 9 Jul 2009 04:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
In-Reply-To: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <729867676.1247128349749.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Halliday reassigned JBAS-7086:
---------------------------------------

    Assignee: Jesper Pedersen  (was: Jonathan Halliday)


> Can't enlist in transaction with second Oracle XA connection/resource.
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7086
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager (Arjuna)
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: The operating system has been windows, but that doesn't appear to be related.
> Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
>            Reporter: Kevin Bates
>            Assignee: Jesper Pedersen
>
> We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.
> At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:
> 2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
> oracle.jdbc.xa.OracleXAException
> 	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
> 	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
> 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
> com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
> 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
> 	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
> 	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
> 	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:404)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy134.executeChanges(Unknown Source)
> 	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:378)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy135.executeChanges(Unknown Source)
> 	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
> 	at java.security.AccessController.doPrivileged(AccessController.java:284)
> 	at javax.security.auth.Subject.doAs(Subject.java:573)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
> 	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
> 	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:735)
> Caused by: 
> org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
> 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 	... 90 more
> Caused by: 
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 	... 92 more
> Caused by: 
> javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	... 96 more
> The two XA data sources are configured as follows:
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">OS1</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraGCDDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">GCD</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.
> Kind regards.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 04:38:41 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 04:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <137792606.1247128721530.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475577#action_12475577 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

As of cp08/1.4.4.GA, the RotatingID's algorithm has been changed because of the enlargement of that range of nodeID.

The new structure of a ID is like:

[16 bits node id] + [34 bits time] + [14 bits counter]

However the code is not implementing this structure:

      long id1 = nodeID << 48;

      long id2 = System.currentTimeMillis() << 14;

      long id = id1 | id2 | count;

and the counter is a short type value, it should be 15 bit (minus the highest sign bit).

So we can re-design the structure as:

[16 bits node id] + [33 bits time] + [15 bits counter]

Another issue is how we take the time bits off the system time (a long value). We know the upper bits of the system
changes very slow (it takes a very long time to make the 40th bit increase by one for example). So we should take the lower part.

If we take bit0 (lowest bit) to bit 32, that means for every millisecond, this field will change by one. To make this field have two same value, you need

2^33 milliseconds, that's about 2^33 / 1000 / 3600 / 24 = 99 days.

However, to make two messages have same ID, the first message must keep in the DB for at least 99 days (and for each 99 days interval thereafter). And the second message
must be sent on the 99th day within the same millisecond, and the counter value (third field) needs to be the same as the first one.

Or, in another case, if the sending rate of messages within one node is equal to or greater than 32767 (short.MAX_VALUE) messages per millisecond, and those messages are all stored in DB at the moment,
there is a chance of two messages having identical IDs.






> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 04:42:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Jul 2009 04:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2104534679.1247128949410.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475579#action_12475579 ] 

Tim Fox commented on JBMESSAGING-1682:
--------------------------------------

Ouch. Can you also post a link to the JIRA in CP08 where the algorithm got broken.

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 04:44:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 04:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1262491920.1247129069205.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475580#action_12475580 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

about the algorithm, we need to clear the higher 16 bits of the time field and also clear the higher 2 bits of the counter before they 'OR'ed together.


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 04:46:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 04:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1682) duplicate key
 value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <910989388.1247129189206.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1682:
------------------------------------

        Fix Version/s: 1.4.0.SP3.CP09
                       1.4.5.GA
    Affects Version/s: 1.4.4.GA
                       1.4.0.SP3.CP08


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 04:51:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Jul 2009 04:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1682) duplicate key
 value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1796571985.1247129489789.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1682:
---------------------------------

    Priority: Critical  (was: Major)


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Critical
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 05:09:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 9 Jul 2009 05:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1865) Upgrade to
 hibernate-core 3.3.1.GA
Message-ID: <15876972.1247130569212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade to hibernate-core 3.3.1.GA
----------------------------------

                 Key: EJBTHREE-1865
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1865
             Project: EJB 3.0
          Issue Type: Thirdparty Change
          Components: core
    Affects Versions: 1.1.8
            Reporter: jaikiran pai
            Assignee: jaikiran pai


Right now the core depends on:

     <dependency>
       <groupId>org.hibernate</groupId>
      <artifactId>hibernate</artifactId>
      <version>3.2.6.ga</version>
     </dependency>

Furthermore, org.hibernate:hibernate is a banned dependency in AS https://jira.jboss.org/jira/browse/JBAS-6904

Move to org.hibernate:hibernate-core 3.3.1.GA


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 05:31:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 9 Jul 2009 05:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1865) Upgrade to
 hibernate-core 3.3.1.GA
In-Reply-To: <15876972.1247130569212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <898312962.1247131889087.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1865.
------------------------------------

    Fix Version/s: 1.1.9
       Resolution: Done


> Upgrade to hibernate-core 3.3.1.GA
> ----------------------------------
>
>                 Key: EJBTHREE-1865
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1865
>             Project: EJB 3.0
>          Issue Type: Thirdparty Change
>          Components: core
>    Affects Versions: 1.1.8
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 1.1.9
>
>
> Right now the core depends on:
>      <dependency>
>        <groupId>org.hibernate</groupId>
>       <artifactId>hibernate</artifactId>
>       <version>3.2.6.ga</version>
>      </dependency>
> Furthermore, org.hibernate:hibernate is a banned dependency in AS https://jira.jboss.org/jira/browse/JBAS-6904
> Move to org.hibernate:hibernate-core 3.3.1.GA

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 06:43:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 9 Jul 2009 06:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-213) Expose
 SchemaBindingValidator as an interface
Message-ID: <461919193.1247136209578.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Expose SchemaBindingValidator as an interface
---------------------------------------------

                 Key: JBXB-213
                 URL: https://jira.jboss.org/jira/browse/JBXB-213
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Feature Request
    Affects Versions: JBossXB-2.0.2.Beta1
            Reporter: Ales Justin
            Assignee: Ales Justin


Expose current class SchemaBindingValidator as an interface,
moving the current impl to DefaultSchemaBindingValidator.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 07:18:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 9 Jul 2009 07:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBXB-213) Expose
 SchemaBindingValidator as an interface
In-Reply-To: <461919193.1247136209578.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1439789909.1247138309187.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBXB-213.
------------------------------

    Resolution: Done


> Expose SchemaBindingValidator as an interface
> ---------------------------------------------
>
>                 Key: JBXB-213
>                 URL: https://jira.jboss.org/jira/browse/JBXB-213
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>    Affects Versions: JBossXB-2.0.2.Beta1
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>
> Expose current class SchemaBindingValidator as an interface,
> moving the current impl to DefaultSchemaBindingValidator.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 08:10:29 2009
From: jira-events at lists.jboss.org (anil kumar (JIRA))
Date: Thu, 9 Jul 2009 08:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7088) expressions like
 'ne', 'eq' are not working in jboss
Message-ID: <170839805.1247141429138.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

expressions like 'ne','eq' are not working in jboss
---------------------------------------------------

                 Key: JBAS-7088
                 URL: https://jira.jboss.org/jira/browse/JBAS-7088
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JSF
    Affects Versions: JBossAS-5.1.0.GA
         Environment: windows
            Reporter: anil kumar
            Assignee: Stan Silvert


<h:dataTable value="#{HeaderBean.records}" var="screenConfig">
              <h:column rendered="#{screenConfig.displayTitle ne 'dashboard'}">
              <h:outputText  value="#{screenConfig.displayTitle}"> </h:outputText>
               </h:column>
  </h:dataTable>
 expressions like 'ne','eq' are not working in jboss but its working fine in Glassfish.
 please suggest me on fixing this issue.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 08:56:40 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 9 Jul 2009 08:56:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1010) TCPGOSSIP / TUNNEL:
 handle reconnecting on disconnect
Message-ID: <989573753.1247144200896.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

TCPGOSSIP / TUNNEL: handle reconnecting on disconnect
-----------------------------------------------------

                 Key: JGRP-1010
                 URL: https://jira.jboss.org/jira/browse/JGRP-1010
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.8


When a GossipRouter is not running, a RouterStub emits a callback that it failed to connect. The callback should schedule a recurring connect() task, until it succeeds. This should be done in both TUNNEL (done in 2.6.x, but not currently working in 2.8, due to the GR changes) and TCPGOSSIP (not even implemented in 2.6.x !).
The reconnect logic needs to work with shared transports as well.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 08:58:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 9 Jul 2009 08:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1010) TCPGOSSIP /
 TUNNEL: handle reconnecting on disconnect
In-Reply-To: <989573753.1247144200896.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <102426613.1247144309133.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475602#action_12475602 ] 

Bela Ban commented on JGRP-1010:
--------------------------------

If we have 2 GossipRouters A and B configured, and only B is disconnected, we need to make sure A does *not* reconnect again, or that if it does, a duplicate CONNECT message is discarded at the GR.

> TCPGOSSIP / TUNNEL: handle reconnecting on disconnect
> -----------------------------------------------------
>
>                 Key: JGRP-1010
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1010
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> When a GossipRouter is not running, a RouterStub emits a callback that it failed to connect. The callback should schedule a recurring connect() task, until it succeeds. This should be done in both TUNNEL (done in 2.6.x, but not currently working in 2.8, due to the GR changes) and TCPGOSSIP (not even implemented in 2.6.x !).
> The reconnect logic needs to work with shared transports as well.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 09:34:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 9 Jul 2009 09:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-110) Use remotable POJO
	naming server
Message-ID: <337769786.1247146469111.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Use remotable POJO naming server
--------------------------------

                 Key: JBJCA-110
                 URL: https://jira.jboss.org/jira/browse/JBJCA-110
             Project: JBoss JCA
          Issue Type: Task
          Components: Standalone
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Switch to a remotable POJO naming server and allow the user to bind the address via a "-b" startup option.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 09:36:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 9 Jul 2009 09:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-110) Use remotable POJO
	naming server
In-Reply-To: <337769786.1247146469111.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <320114049.1247146589303.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-110.
-----------------------------------

    Resolution: Done


> Use remotable POJO naming server
> --------------------------------
>
>                 Key: JBJCA-110
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-110
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Standalone
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Switch to a remotable POJO naming server and allow the user to bind the address via a "-b" startup option.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 09:45:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 09:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <534634309.1247147129286.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475611#action_12475611 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

The id can be generated using the following modified code:


      long id1 = nodeID << 48;

      long id2 = (System.currentTimeMillis() << 15) & 0x0000FFFFFFFFFFFFL; //reserve the high 16 bits for node id

      long id = id1 | id2 | count;


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Critical
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 09:47:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 09:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <637268416.1247147249373.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475612#action_12475612 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

[quote]
Or, in another case, if the sending rate of messages within one node is equal to or greater than 32767 (short.MAX_VALUE) messages per millisecond, and those messages are all stored in DB at the moment,
there is a chance of two messages having identical IDs.
[/quote]

The above case has already been taken care of in the code, so it is eliminated.



> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Critical
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 09:51:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 09:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1682) duplicate key
 value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1229577685.1247147489212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1682.
-----------------------------------

    Resolution: Done


Done.

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Critical
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 10:14:29 2009
From: jira-events at lists.jboss.org (anil kumar (JIRA))
Date: Thu, 9 Jul 2009 10:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7089) <h:column> level
 rendering is not working in JBOSS
Message-ID: <1328936593.1247148869241.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

<h:column> level rendering is not working in JBOSS 
---------------------------------------------------

                 Key: JBAS-7089
                 URL: https://jira.jboss.org/jira/browse/JBAS-7089
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JSF
    Affects Versions: JBossAS-5.1.0.GA
         Environment: windows
            Reporter: anil kumar
            Assignee: Stan Silvert


<h:column> level rendering is not working in JBOSS but works in Glassfish.

   <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
             <h:column>
             <h:outputText  value="#{screenConfig.displayTitle}"  rendered="#{'5' eq '5'}"> </h:outputText>   
              </h:column>  
         </h:dataTable> 

this is working perfectly.




<h:dataTable value="#{HeaderBean.records}" var="screenConfig">
             <h:column  rendered="#{'5' eq '5'}"> >
             <h:outputText  value="#{screenConfig.displayTitle}" </h:outputText>   
              </h:column>  
         </h:dataTable> 

where as above one is not working. I really don't understand why this is not working in JBOSS.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 10:39:29 2009
From: jira-events at lists.jboss.org (Kit Chan (JIRA))
Date: Thu, 9 Jul 2009 10:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2201) Rule got executed
 even does not satisfy LHS after firing an external event in Flow
In-Reply-To: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <449088057.1247150369309.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kit Chan updated JBRULES-2201:
------------------------------

    Component/s: drools-core (flow)
       Priority: Critical  (was: Major)


> Rule got executed even does not satisfy LHS after firing an external event in Flow
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2201
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert), drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP SP3, Eclipse 3.4.2
>            Reporter: Kit Chan
>            Assignee: Mark Proctor
>            Priority: Critical
>
> I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 11:16:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Jul 2009 11:16:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <238381023.1247152589249.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox reopened JBMESSAGING-1682:
----------------------------------



> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Critical
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 11:18:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Jul 2009 11:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1682) duplicate key
 value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <156865431.1247152709233.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1682:
---------------------------------

    Priority: Blocker  (was: Critical)


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 11:55:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Thu, 9 Jul 2009 11:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7089) <h:column> level
 rendering is not working in JBOSS
In-Reply-To: <1328936593.1247148869241.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <858302133.1247154929191.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475639#action_12475639 ] 

Stan Silvert commented on JBAS-7089:
------------------------------------

Your second example has an extra > at the end of the column tag.  Fix that first.  If it still fails, post the error.

> <h:column> level rendering is not working in JBOSS 
> ---------------------------------------------------
>
>                 Key: JBAS-7089
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7089
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: windows
>            Reporter: anil kumar
>            Assignee: Stan Silvert
>
> <h:column> level rendering is not working in JBOSS but works in Glassfish.
>    <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
>              <h:column>
>              <h:outputText  value="#{screenConfig.displayTitle}"  rendered="#{'5' eq '5'}"> </h:outputText>   
>               </h:column>  
>          </h:dataTable> 
> this is working perfectly.
> <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
>              <h:column  rendered="#{'5' eq '5'}"> >
>              <h:outputText  value="#{screenConfig.displayTitle}" </h:outputText>   
>               </h:column>  
>          </h:dataTable> 
> where as above one is not working. I really don't understand why this is not working in JBOSS.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 11:57:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Thu, 9 Jul 2009 11:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7089) <h:column> level
 rendering is not working in JBOSS
In-Reply-To: <1328936593.1247148869241.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2101497686.1247155049162.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert updated JBAS-7089:
-------------------------------

    Labels:   (was: column  level rendering is not working in JBOSS )


> <h:column> level rendering is not working in JBOSS 
> ---------------------------------------------------
>
>                 Key: JBAS-7089
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7089
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: windows
>            Reporter: anil kumar
>            Assignee: Stan Silvert
>
> <h:column> level rendering is not working in JBOSS but works in Glassfish.
>    <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
>              <h:column>
>              <h:outputText  value="#{screenConfig.displayTitle}"  rendered="#{'5' eq '5'}"> </h:outputText>   
>               </h:column>  
>          </h:dataTable> 
> this is working perfectly.
> <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
>              <h:column  rendered="#{'5' eq '5'}"> >
>              <h:outputText  value="#{screenConfig.displayTitle}" </h:outputText>   
>               </h:column>  
>          </h:dataTable> 
> where as above one is not working. I really don't understand why this is not working in JBOSS.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 12:01:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Thu, 9 Jul 2009 12:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7089) <h:column> level
 rendering is not working in JBOSS
In-Reply-To: <1328936593.1247148869241.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1882705085.1247155289147.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475640#action_12475640 ] 

Stan Silvert commented on JBAS-7089:
------------------------------------

Your outputText tag is also invalid.

> <h:column> level rendering is not working in JBOSS 
> ---------------------------------------------------
>
>                 Key: JBAS-7089
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7089
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: windows
>            Reporter: anil kumar
>            Assignee: Stan Silvert
>
> <h:column> level rendering is not working in JBOSS but works in Glassfish.
>    <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
>              <h:column>
>              <h:outputText  value="#{screenConfig.displayTitle}"  rendered="#{'5' eq '5'}"> </h:outputText>   
>               </h:column>  
>          </h:dataTable> 
> this is working perfectly.
> <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
>              <h:column  rendered="#{'5' eq '5'}"> >
>              <h:outputText  value="#{screenConfig.displayTitle}" </h:outputText>   
>               </h:column>  
>          </h:dataTable> 
> where as above one is not working. I really don't understand why this is not working in JBOSS.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 12:20:40 2009
From: jira-events at lists.jboss.org (Rinat Gareev (JIRA))
Date: Thu, 9 Jul 2009 12:20:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1866) EJB deployer
 require mapped name for SessionContext injection
Message-ID: <1953202672.1247156440396.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

EJB deployer require mapped name for SessionContext injection
-------------------------------------------------------------

                 Key: EJBTHREE-1866
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1866
             Project: EJB 3.0
          Issue Type: Bug
          Components: core
    Affects Versions: 1.1.5
            Reporter: Rinat Gareev


EJB deployer require mapped name for SessionContext injection

EJB class:

@Stateful
@EJBs
		({
				@EJB (beanInterface = CoreSecurityFacade.class, beanName = "CoreSecurityFacadeBean",
						name = "ejb/CoreSecurityFacade"),
				@EJB (beanInterface = CoreApplicationsFacade.class, beanName = "CoreApplicationsFacadeBean",
						name = "ejb/CoreApplicationsFacade"),
				@EJB (beanInterface = CoreConfigFacade.class, beanName = "CoreConfigFacadeBean",
						name = "ejb/CoreConfigFacade")
		})
public class CoreFacadeFactoryBean implements CoreFacadeFactory, Serializable
{
	@Resource
	private SessionContext ctx;
....content omitted
}

Root cause:

Caused by: java.lang.RuntimeException: You did not specify a @Resource.mappedName() on private javax.ejb.SessionContext rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean.ctx and there is no binding for enc name env/rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean/ctx in XML                                                                                 
        at org.jboss.injection.ResourceHandler.handlePropertyAnnotation(ResourceHandler.java:684)                                                                                   
        at org.jboss.injection.ResourceHandler.handleFieldAnnotations(ResourceHandler.java:497)                                                                                     
        at org.jboss.injection.InjectionUtil.processFieldAnnotations(InjectionUtil.java:160)                                                                                        
        at org.jboss.injection.InjectionUtil.processAnnotations(InjectionUtil.java:197)                                                                                             
        at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:590)                                                                                                       
        at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
        at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
        ... 35 more


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 12:22:29 2009
From: jira-events at lists.jboss.org (Rinat Gareev (JIRA))
Date: Thu, 9 Jul 2009 12:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1866) EJB deployer
 requires mapped name for SessionContext injection
In-Reply-To: <1953202672.1247156440396.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <585540093.1247156549112.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rinat Gareev updated EJBTHREE-1866:
-----------------------------------

        Summary: EJB deployer requires mapped name for SessionContext injection  (was: EJB deployer require mapped name for SessionContext injection)
    Environment: JBoss 5.1.0 GA


> EJB deployer requires mapped name for SessionContext injection
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-1866
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1866
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>         Environment: JBoss 5.1.0 GA
>            Reporter: Rinat Gareev
>
> EJB deployer require mapped name for SessionContext injection
> EJB class:
> @Stateful
> @EJBs
> 		({
> 				@EJB (beanInterface = CoreSecurityFacade.class, beanName = "CoreSecurityFacadeBean",
> 						name = "ejb/CoreSecurityFacade"),
> 				@EJB (beanInterface = CoreApplicationsFacade.class, beanName = "CoreApplicationsFacadeBean",
> 						name = "ejb/CoreApplicationsFacade"),
> 				@EJB (beanInterface = CoreConfigFacade.class, beanName = "CoreConfigFacadeBean",
> 						name = "ejb/CoreConfigFacade")
> 		})
> public class CoreFacadeFactoryBean implements CoreFacadeFactory, Serializable
> {
> 	@Resource
> 	private SessionContext ctx;
> ....content omitted
> }
> Root cause:
> Caused by: java.lang.RuntimeException: You did not specify a @Resource.mappedName() on private javax.ejb.SessionContext rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean.ctx and there is no binding for enc name env/rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean/ctx in XML                                                                                 
>         at org.jboss.injection.ResourceHandler.handlePropertyAnnotation(ResourceHandler.java:684)                                                                                   
>         at org.jboss.injection.ResourceHandler.handleFieldAnnotations(ResourceHandler.java:497)                                                                                     
>         at org.jboss.injection.InjectionUtil.processFieldAnnotations(InjectionUtil.java:160)                                                                                        
>         at org.jboss.injection.InjectionUtil.processAnnotations(InjectionUtil.java:197)                                                                                             
>         at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:590)                                                                                                       
>         at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
>         at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
>         ... 35 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 12:24:29 2009
From: jira-events at lists.jboss.org (Rinat Gareev (JIRA))
Date: Thu, 9 Jul 2009 12:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1866) EJB deployer
 requires mapped name for SessionContext injection
In-Reply-To: <1953202672.1247156440396.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1414793665.1247156669077.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rinat Gareev updated EJBTHREE-1866:
-----------------------------------

    Attachment: server.log


server.log content for EAR deploying time

> EJB deployer requires mapped name for SessionContext injection
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-1866
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1866
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>         Environment: JBoss 5.1.0 GA
>            Reporter: Rinat Gareev
>         Attachments: server.log
>
>
> EJB deployer require mapped name for SessionContext injection
> EJB class:
> @Stateful
> @EJBs
> 		({
> 				@EJB (beanInterface = CoreSecurityFacade.class, beanName = "CoreSecurityFacadeBean",
> 						name = "ejb/CoreSecurityFacade"),
> 				@EJB (beanInterface = CoreApplicationsFacade.class, beanName = "CoreApplicationsFacadeBean",
> 						name = "ejb/CoreApplicationsFacade"),
> 				@EJB (beanInterface = CoreConfigFacade.class, beanName = "CoreConfigFacadeBean",
> 						name = "ejb/CoreConfigFacade")
> 		})
> public class CoreFacadeFactoryBean implements CoreFacadeFactory, Serializable
> {
> 	@Resource
> 	private SessionContext ctx;
> ....content omitted
> }
> Root cause:
> Caused by: java.lang.RuntimeException: You did not specify a @Resource.mappedName() on private javax.ejb.SessionContext rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean.ctx and there is no binding for enc name env/rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean/ctx in XML                                                                                 
>         at org.jboss.injection.ResourceHandler.handlePropertyAnnotation(ResourceHandler.java:684)                                                                                   
>         at org.jboss.injection.ResourceHandler.handleFieldAnnotations(ResourceHandler.java:497)                                                                                     
>         at org.jboss.injection.InjectionUtil.processFieldAnnotations(InjectionUtil.java:160)                                                                                        
>         at org.jboss.injection.InjectionUtil.processAnnotations(InjectionUtil.java:197)                                                                                             
>         at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:590)                                                                                                       
>         at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
>         at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
>         ... 35 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 12:26:29 2009
From: jira-events at lists.jboss.org (Rinat Gareev (JIRA))
Date: Thu, 9 Jul 2009 12:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1866) EJB deployer
 requires mapped name for SessionContext injection
In-Reply-To: <1953202672.1247156440396.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <641648487.1247156789127.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rinat Gareev updated EJBTHREE-1866:
-----------------------------------

    Attachment: ejb-jar.xml


ejb-jar.xml of according EJB module

> EJB deployer requires mapped name for SessionContext injection
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-1866
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1866
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>         Environment: JBoss 5.1.0 GA
>            Reporter: Rinat Gareev
>         Attachments: ejb-jar.xml, server.log
>
>
> EJB deployer require mapped name for SessionContext injection
> EJB class:
> @Stateful
> @EJBs
> 		({
> 				@EJB (beanInterface = CoreSecurityFacade.class, beanName = "CoreSecurityFacadeBean",
> 						name = "ejb/CoreSecurityFacade"),
> 				@EJB (beanInterface = CoreApplicationsFacade.class, beanName = "CoreApplicationsFacadeBean",
> 						name = "ejb/CoreApplicationsFacade"),
> 				@EJB (beanInterface = CoreConfigFacade.class, beanName = "CoreConfigFacadeBean",
> 						name = "ejb/CoreConfigFacade")
> 		})
> public class CoreFacadeFactoryBean implements CoreFacadeFactory, Serializable
> {
> 	@Resource
> 	private SessionContext ctx;
> ....content omitted
> }
> Root cause:
> Caused by: java.lang.RuntimeException: You did not specify a @Resource.mappedName() on private javax.ejb.SessionContext rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean.ctx and there is no binding for enc name env/rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean/ctx in XML                                                                                 
>         at org.jboss.injection.ResourceHandler.handlePropertyAnnotation(ResourceHandler.java:684)                                                                                   
>         at org.jboss.injection.ResourceHandler.handleFieldAnnotations(ResourceHandler.java:497)                                                                                     
>         at org.jboss.injection.InjectionUtil.processFieldAnnotations(InjectionUtil.java:160)                                                                                        
>         at org.jboss.injection.InjectionUtil.processAnnotations(InjectionUtil.java:197)                                                                                             
>         at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:590)                                                                                                       
>         at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
>         at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
>         ... 35 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 12:31:40 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Jul 2009 12:31:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <177593462.1247157100984.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475643#action_12475643 ] 

Tim Fox commented on JBMESSAGING-1682:
--------------------------------------

I re-opened this because Howard's latest fix only allows 33 bits for the time component:

16 bits node id + 32 bits time + 14 bits counter.

This only allows dates up to:

(2^33-1)/1000/60/60/24/365.25 years since Jan 1 1970, which is only a few months!!

So this is clearly broken still. We cannot allow collisions within a reasonable time range (say 100 years or so).

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 12:39:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 9 Jul 2009 12:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <565747844.1247157569225.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475645#action_12475645 ] 

Tim Fox commented on JBMESSAGING-1682:
--------------------------------------

Correction, it's 34 bits for time

So that's (2^35-1)/1000/60/60/24/365.25 = which is just over 1 year sine 1 Jan 1970. Still not enough

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 13:43:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 9 Jul 2009 13:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1866) EJB deployer
 requires mapped name for SessionContext injection
In-Reply-To: <1953202672.1247156440396.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <547864575.1247161409149.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475654#action_12475654 ] 

jaikiran pai commented on EJBTHREE-1866:
----------------------------------------

It works fine for me. Can you attach the application which is failing? Also are you packaging any jar containing javax.ejb.* in your application? If yes remove those jars and try it out.

> EJB deployer requires mapped name for SessionContext injection
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-1866
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1866
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>         Environment: JBoss 5.1.0 GA
>            Reporter: Rinat Gareev
>         Attachments: ejb-jar.xml, server.log
>
>
> EJB deployer require mapped name for SessionContext injection
> EJB class:
> @Stateful
> @EJBs
> 		({
> 				@EJB (beanInterface = CoreSecurityFacade.class, beanName = "CoreSecurityFacadeBean",
> 						name = "ejb/CoreSecurityFacade"),
> 				@EJB (beanInterface = CoreApplicationsFacade.class, beanName = "CoreApplicationsFacadeBean",
> 						name = "ejb/CoreApplicationsFacade"),
> 				@EJB (beanInterface = CoreConfigFacade.class, beanName = "CoreConfigFacadeBean",
> 						name = "ejb/CoreConfigFacade")
> 		})
> public class CoreFacadeFactoryBean implements CoreFacadeFactory, Serializable
> {
> 	@Resource
> 	private SessionContext ctx;
> ....content omitted
> }
> Root cause:
> Caused by: java.lang.RuntimeException: You did not specify a @Resource.mappedName() on private javax.ejb.SessionContext rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean.ctx and there is no binding for enc name env/rs.diving.ubcc.core.core.core.CoreFacadeFactoryBean/ctx in XML                                                                                 
>         at org.jboss.injection.ResourceHandler.handlePropertyAnnotation(ResourceHandler.java:684)                                                                                   
>         at org.jboss.injection.ResourceHandler.handleFieldAnnotations(ResourceHandler.java:497)                                                                                     
>         at org.jboss.injection.InjectionUtil.processFieldAnnotations(InjectionUtil.java:160)                                                                                        
>         at org.jboss.injection.InjectionUtil.processAnnotations(InjectionUtil.java:197)                                                                                             
>         at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:590)                                                                                                       
>         at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418)
>         at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527)
>         ... 35 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 14:44:29 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Thu, 9 Jul 2009 14:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6936) Testsuite fails
 during
 tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
In-Reply-To: <368622.1242662765255.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <668424109.1247165069260.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6936:
---------------------------------

    Attachment: threadDump.html


Thread dump taken when server failed to restart.  Also reproducable on trunk.

> Testsuite fails during tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6936
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6936
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: threadDump.html
>
>
> The AS fails to start for the second time during the tests-profileservice target of the testsuite. This is caused by the first instance not being properly shutdown by the following ant command: <server:stop name="profileservice"/>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 15:06:29 2009
From: jira-events at lists.jboss.org (Irena Shaigorodsky (JIRA))
Date: Thu, 9 Jul 2009 15:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7090)
 org.jboss.jdbc.DerbyDatabase used
 by varia example has a bug and never attempts to shut down derby database
Message-ID: <627780683.1247166389107.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

org.jboss.jdbc.DerbyDatabase used by varia example has a bug and never attempts to shut down derby database
-----------------------------------------------------------------------------------------------------------

                 Key: JBAS-7090
                 URL: https://jira.jboss.org/jira/browse/JBAS-7090
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-4.0.5.GA
         Environment: JBoss 4.0.5.GA and JBoss 4.2.3.GA
            Reporter: Irena Shaigorodsky


org.jboss.jdbc.DerbyDatabase used by varia example has a following bug. 
1. connection member is created at service start-up
2. getConnection(String dbURL) creates new connection only if connection member is null
3. on service shut down when getConnection("jdbc:derby:;shutdown=true"); is called nothing happens and Derby is not brought down.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 16:49:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 9 Jul 2009 16:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1607242517.1247172569213.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBAS-7049:
--------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242715


> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 17:24:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 9 Jul 2009 17:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2202) Generated types
 should be Serializable
Message-ID: <1963762277.1247174669126.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Generated types should be Serializable
--------------------------------------

                 Key: JBRULES-2202
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2202
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler, drools-core
    Affects Versions: 5.0.1.FINAL, 5.0.0.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


Hello,

Recently I've been working with Drools version 5.0.1 to set up an event processor.  While doing so I have come
across difficulties with the accumulate function, in that it will always throw a ClassCastException
when inserting events that are declared within my drl file.  To illustrate this I've set up an example which is
shown below.  I've search Google and the mailing list for several hours, but the only way past this problem
appears to be that I will have to declare a class externally and make sure it implements Serializable.  Does
anyone has suggestions for another approach?  Secondly, I would have assumed that since Drools was
compiling these internally declared classes, that Serializable would have been implemented automatically.  So
is this a result of the generated class not implementing Serializable, or have I missed something in my rules
file?  Thanks.

The important part of my drl file is:

declare TestEvent
   @role( event )
   @expires(10s)
   id : String
end

#This rule works fine when 'Accumulate Count' is commented out, and is used to make
#sure that the event inserting has worked.
rule "Is It There"
    when
        TestEvent() from entry-point "test"
    then
        System.out.println("Found a TestEvent.");
end

#This rule throws a ClassCastException when a TestEvent is inserted.
rule "Accumulate Count"
    when
        $n : Number() from accumulate($t : TestEvent() from entry-point "test",    count($t))
    then
        System.out.println("Found " + $n + " events.");
end

The unit test does this:

FactType testEventType = session.getKnowledgeBase().getFactType("com.drools.test", "TestEvent");
for(int i = 0; i < 10; i++){
    Object testEvent = testEventType.newInstance();
    testEventType.set(testEvent, "id", "id");
    WorkingMemoryEntryPoint mainStream = session.getWorkingMemoryEntryPoint("test");
    mainStream.insert(event);
    session.fireAllRules();
}

The exception I receive is:

org.drools.RuntimeDroolsException: java.lang.ClassCastException: com.drools.test.TestEvent cannot be cast to java.io.Serializable
    at org.drools.rule.Accumulate.accumulate(Accumulate.java:172)
    at org.drools.reteoo.AccumulateNode.modifyTuple(AccumulateNode.java:424)
    at org.drools.reteoo.AccumulateNode.assertObject(AccumulateNode.java:284)
    at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:42)
    at org.drools.reteoo.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:326)
    at org.drools.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:221)
    at org.drools.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:394)
    at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1486)
    at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:158)
    at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:122)
    at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:80)
    at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:28)
    at com.drools.test.MyUnitTest.testEvents(EvaluationTest.java:66)
    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.springframework.test.context.junit4.SpringTestMethod.invoke(SpringTestMethod.java:160)
    at org.springframework.test.context.junit4.SpringMethodRoadie.runTestMethod(SpringMethodRoadie.java:233)
    at org.springframework.test.context.junit4.SpringMethodRoadie$RunBeforesThenTestThenAfters.run(SpringMethodRoadie.java:333)
    at org.springframework.test.context.junit4.SpringMethodRoadie.runWithRepetitions(SpringMethodRoadie.java:217)
    at org.springframework.test.context.junit4.SpringMethodRoadie.runTest(SpringMethodRoadie.java:197)
    at org.springframework.test.context.junit4.SpringMethodRoadie.run(SpringMethodRoadie.java:143)
    at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.invokeTestMethod(SpringJUnit4ClassRunner.java:160)
    at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
    at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
    at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
    at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
    at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
    at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:97)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
    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)
Caused by: java.lang.ClassCastException: com.drools.test.TestEvent cannot be cast to java.io.Serializable
    at org.drools.base.accumulators.JavaAccumulatorFunctionExecutor.accumulate(JavaAccumulatorFunctionExecutor.java:110)
    at org.drools.rule.Accumulate.accumulate(Accumulate.java:164)
    ... 36 more


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 17:36:29 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Thu, 9 Jul 2009 17:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6936) Testsuite fails
 during
 tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
In-Reply-To: <368622.1242662765255.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <766635278.1247175389112.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6936:
---------------------------------


After looking at the thread dump, it looks like this is related to  a RichFaces bug, https://jira.jboss.org/jira/browse/RF-4537.
The tests-profileservice target also runs the org.jboss.deployers.seam tests.  During the run, two tests fail due to timeout:
org.jboss.test.deployers.seam.test.SeamBookingExampleUnitTestCase FAILED (timeout)
org.jboss.test.deployers.seam.test.SeamJpaExampleUnitTestCase FAILED (timeout)

The RichFaces bug is marked FIXED with RichFaces 3.3.0.GA.  The version of RichFaces packaged in these test archives is 3.2.2.GA.
I'll verify this by updating the test jars to 3.3.0/3.3.1.
See also: https://jira.jboss.org/jira/browse/JBSEAM-3570

> Testsuite fails during tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6936
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6936
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: threadDump.html
>
>
> The AS fails to start for the second time during the tests-profileservice target of the testsuite. This is caused by the first instance not being properly shutdown by the following ant command: <server:stop name="profileservice"/>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 17:59:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 9 Jul 2009 17:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <304129068.1247176769211.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475676#action_12475676 ] 

Anil Saldhana commented on JBAS-7049:
-------------------------------------

OpenJDK6 bug which has been fixed in OpenJDK7.  The forum thread has the details.

> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 18:27:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 9 Jul 2009 18:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1676550187.1247178449286.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475682#action_12475682 ] 

Anil Saldhana commented on JBAS-7049:
-------------------------------------

DML has created an issue in iced tea: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=364

> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 18:36:29 2009
From: jira-events at lists.jboss.org (Konstantin Pupkov (JIRA))
Date: Thu, 9 Jul 2009 18:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <712267433.1247178989210.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475683#action_12475683 ] 

Konstantin Pupkov commented on JBMESSAGING-1681:
------------------------------------------------

here is link: http://www.jboss.org/ejb3/docs.html

search for "Tutorials (Source)" section. 
Then download source in zip archive. In source follow by "/ejb3-tutorials/source/mdb/" path.

> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 19:57:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 9 Jul 2009 19:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-1141) HTTPUnMarshaller
 should test for
 "non-text" content-type instead of "binary" content-type
Message-ID: <1486017658.1247183849135.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

HTTPUnMarshaller should test for "non-text" content-type instead of "binary" content-type
-----------------------------------------------------------------------------------------

                 Key: JBREM-1141
                 URL: https://jira.jboss.org/jira/browse/JBREM-1141
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.3, 2.5.1 (Flounder)
            Reporter: Ron Sigal
            Assignee: Ron Sigal
             Fix For: 2.5.2 (Flounder), 2.2.3.SP1


As an efficiency measure, org.jboss.marshal.http.HTTPUnMarshaller.read() incorporates special handling for strings to avoid serialization.  However, there is a flaw in the logic.

HTTPUnMarshaller.read() calls isBinaryData() and calls super.read() if the return value is true.  If the return value is false, then it processes the input as String data.  Originally, this distinction worked because the only two types recognized were org.jboss.remoting..transport.web.WebUtil.HTML ("text/html") and WebUtil.BINARY ("application/octet-stream").  However, JBREM-653 "allow user to set content-type for http responses" allows the introduction of other content types.

Instead of testing for "application/octet-stream", HTTPUnMarshaller.read() should treat any content type that starts "text" as a String, and it should treat anything else as an object.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 22:52:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Thu, 9 Jul 2009 22:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-1142) Clarify use of
 "clientConnectAddress" in RemotingGuide
Message-ID: <1414608541.1247194349236.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Clarify use of "clientConnectAddress" in RemotingGuide
------------------------------------------------------

                 Key: JBREM-1142
                 URL: https://jira.jboss.org/jira/browse/JBREM-1142
             Project: JBoss Remoting
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: docs
    Affects Versions: 2.2.3, 2.5.1 (Flounder)
            Reporter: Ron Sigal
            Assignee: Ron Sigal
             Fix For: 2.5.2 (Flounder), 2.2.3.SP1


The Remoting Guide should spell out the fact that the parameter "clientConnectAddress" is useful only in the context of server side configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 23:04:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 9 Jul 2009 23:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCL-109) Infinite loop when a
 legit LinkageError occurs
Message-ID: <157425770.1247195069114.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Infinite loop when a legit LinkageError occurs
----------------------------------------------

                 Key: JBCL-109
                 URL: https://jira.jboss.org/jira/browse/JBCL-109
             Project: JBoss ClassLoader
          Issue Type: Bug
            Reporter: Jason T. Greene
            Priority: Blocker
             Fix For: JBossCL.2.0.7.GA


To fix an old JVM issue, linkage errors are treated like a ClassCircularityException. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-5327), an infinite loop results. 

synchronized int incrementNumCCE()
 {
     return numCCE;;
  }

This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 23:06:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 9 Jul 2009 23:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCL-109) Infinite loop when a
 legit LinkageError occurs
In-Reply-To: <157425770.1247195069114.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1187491261.1247195189644.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBCL-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene updated JBCL-109:
---------------------------------

    Component/s: ClassLoader


> Infinite loop when a legit LinkageError occurs
> ----------------------------------------------
>
>                 Key: JBCL-109
>                 URL: https://jira.jboss.org/jira/browse/JBCL-109
>             Project: JBoss ClassLoader
>          Issue Type: Bug
>          Components: ClassLoader
>            Reporter: Jason T. Greene
>            Priority: Blocker
>             Fix For: JBossCL.2.0.7.GA
>
>
> To fix an old JVM issue, linkage errors are treated like a ClassCircularityException. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-6327), an infinite loop results. 
> synchronized int incrementNumCCE()
>  {
>      return numCCE;;
>   }
> This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 23:06:30 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 9 Jul 2009 23:06:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6327) Servlet hangs in
	classloader
In-Reply-To: <11803824.1229509077422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <134294766.1247195190258.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene reassigned JBAS-6327:
-------------------------------------

    Assignee: Jason T. Greene  (was: Emanuel Muckenhuber)


> Servlet hangs in classloader
> ----------------------------
>
>                 Key: JBAS-6327
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6327
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Testsuite ejb3/servlet
>            Reporter: Carlo de Wolf
>            Assignee: Jason T. Greene
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> "http-localhost%2F127.0.0.1-8080-1" daemon prio=1 tid=0x10ae3118 nid=0x6b36 runnable [0x7897c000..0x7897df20]
> 	at java.lang.ClassLoader.defineClass1(Native Method)
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:62)
> 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:509)
> 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:469)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:467)
> 	- locked <0x9a2ff1a8> (a org.jboss.classloader.spi.base.BaseClassLoader)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:444)
> 	at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
> 	at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
> 	at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
> 	at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:254)
> 	at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:148)
> 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:256)
> 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1099)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:735)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:378)
> 	- locked <0x9a2ff1a8> (a org.jboss.classloader.spi.base.BaseClassLoader)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
> 	- locked <0x9a757fb8> (a org.jboss.web.tomcat.service.WebCtxLoader$ENCLoader)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> 	- locked <0x9a757fb8> (a org.jboss.web.tomcat.service.WebCtxLoader$ENCLoader)
> 	at $Proxy156.getWarTestObject(Unknown Source)
> 	at org.jboss.ejb3.test.servlet.servlets.EJBServlet.processRequest(EJBServlet.java:95)
> 	at org.jboss.ejb3.test.servlet.servlets.EJBServlet.doGet(EJBServlet.java:146)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 23:06:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 9 Jul 2009 23:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCL-109) Infinite loop when a
 legit LinkageError occurs
In-Reply-To: <157425770.1247195069114.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1285636296.1247195189580.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBCL-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene updated JBCL-109:
---------------------------------

    Description: 
To fix an old JVM issue, linkage errors are treated like a ClassCircularityException. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-6327), an infinite loop results. 

synchronized int incrementNumCCE()
 {
     return numCCE;;
  }

This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP


  was:
To fix an old JVM issue, linkage errors are treated like a ClassCircularityException. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-5327), an infinite loop results. 

synchronized int incrementNumCCE()
 {
     return numCCE;;
  }

This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP




> Infinite loop when a legit LinkageError occurs
> ----------------------------------------------
>
>                 Key: JBCL-109
>                 URL: https://jira.jboss.org/jira/browse/JBCL-109
>             Project: JBoss ClassLoader
>          Issue Type: Bug
>          Components: ClassLoader
>            Reporter: Jason T. Greene
>            Priority: Blocker
>             Fix For: JBossCL.2.0.7.GA
>
>
> To fix an old JVM issue, linkage errors are treated like a ClassCircularityException. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-6327), an infinite loop results. 
> synchronized int incrementNumCCE()
>  {
>      return numCCE;;
>   }
> This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 23:06:30 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 9 Jul 2009 23:06:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6327) Servlet hangs in
	classloader
In-Reply-To: <11803824.1229509077422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <306492186.1247195190019.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475687#action_12475687 ] 

Jason T. Greene commented on JBAS-6327:
---------------------------------------

The hang is caused by JBCL-109, which is a bad reaction to a linkage error. The linkage error is caused by a packaging problem in the test.

> Servlet hangs in classloader
> ----------------------------
>
>                 Key: JBAS-6327
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6327
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Testsuite ejb3/servlet
>            Reporter: Carlo de Wolf
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> "http-localhost%2F127.0.0.1-8080-1" daemon prio=1 tid=0x10ae3118 nid=0x6b36 runnable [0x7897c000..0x7897df20]
> 	at java.lang.ClassLoader.defineClass1(Native Method)
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:62)
> 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:509)
> 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:469)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:467)
> 	- locked <0x9a2ff1a8> (a org.jboss.classloader.spi.base.BaseClassLoader)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:444)
> 	at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
> 	at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
> 	at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
> 	at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:254)
> 	at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:148)
> 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:256)
> 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1099)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:735)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:378)
> 	- locked <0x9a2ff1a8> (a org.jboss.classloader.spi.base.BaseClassLoader)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
> 	- locked <0x9a757fb8> (a org.jboss.web.tomcat.service.WebCtxLoader$ENCLoader)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> 	- locked <0x9a757fb8> (a org.jboss.web.tomcat.service.WebCtxLoader$ENCLoader)
> 	at $Proxy156.getWarTestObject(Unknown Source)
> 	at org.jboss.ejb3.test.servlet.servlets.EJBServlet.processRequest(EJBServlet.java:95)
> 	at org.jboss.ejb3.test.servlet.servlets.EJBServlet.doGet(EJBServlet.java:146)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 23:11:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 9 Jul 2009 23:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCL-109) Infinite loop when a
 legit LinkageError occurs
In-Reply-To: <157425770.1247195069114.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <439203951.1247195489718.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBCL-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene resolved JBCL-109.
----------------------------------

    Resolution: Done
      Assignee: Jason T. Greene


> Infinite loop when a legit LinkageError occurs
> ----------------------------------------------
>
>                 Key: JBCL-109
>                 URL: https://jira.jboss.org/jira/browse/JBCL-109
>             Project: JBoss ClassLoader
>          Issue Type: Bug
>          Components: ClassLoader
>            Reporter: Jason T. Greene
>            Assignee: Jason T. Greene
>            Priority: Blocker
>             Fix For: JBossCL.2.0.7.GA
>
>
> To fix an old JVM issue, linkage errors are treated like a ClassCircularityException. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-6327), an infinite loop results. 
> synchronized int incrementNumCCE()
>  {
>      return numCCE;;
>   }
> This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 23:13:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 9 Jul 2009 23:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7091) Incorrect handling
 of timestamps in clustered session
Message-ID: <2099065379.1247195609545.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Incorrect handling of timestamps in clustered session
-----------------------------------------------------

                 Key: JBAS-7091
                 URL: https://jira.jboss.org/jira/browse/JBAS-7091
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering, Web (Tomcat) service
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-5.2.0.Beta1


ClusteredSession has an "outdatedTime" field that records the timestamp when a session gets a callback notifying of a modification on another node.  If the session state later gets updated from the distributed cache, the clearOutdated() method ends up setting the session timestamp to that "outdatedTime" rather than the correct timestamp that's stored in the distributed cache. That's wrong.

Not a big deal, as the difference between the outdatedTime and the correct timestamp is probably just a few ms (time it takes to replicate the session). But still, it's wrong.

In any case the handling of "outdatedTime" is more complex than need and related "outdatedVersion" field can be removed altogether.  There's a bit of cruft here from the old days when correct timestamps weren't readily available from the cache.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 23:18:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 9 Jul 2009 23:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCL-109) Infinite loop when a
 legit LinkageError occurs
In-Reply-To: <157425770.1247195069114.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1462567792.1247195909125.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBCL-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene updated JBCL-109:
---------------------------------

    Description: 
To fix an old JVM issue, linkage errors are treated like a ClassCircularityError. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-6327), an infinite loop results. 

synchronized int incrementNumCCE()
 {
     return numCCE;;
  }

This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP


  was:
To fix an old JVM issue, linkage errors are treated like a ClassCircularityException. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-6327), an infinite loop results. 

synchronized int incrementNumCCE()
 {
     return numCCE;;
  }

This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP




> Infinite loop when a legit LinkageError occurs
> ----------------------------------------------
>
>                 Key: JBCL-109
>                 URL: https://jira.jboss.org/jira/browse/JBCL-109
>             Project: JBoss ClassLoader
>          Issue Type: Bug
>          Components: ClassLoader
>            Reporter: Jason T. Greene
>            Assignee: Jason T. Greene
>            Priority: Blocker
>             Fix For: JBossCL.2.0.7.GA
>
>
> To fix an old JVM issue, linkage errors are treated like a ClassCircularityError. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-6327), an infinite loop results. 
> synchronized int incrementNumCCE()
>  {
>      return numCCE;;
>   }
> This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul  9 23:34:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 9 Jul 2009 23:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1449054916.1247196869166.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475689#action_12475689 ] 

Howard Gao commented on JBMESSAGING-1681:
-----------------------------------------

Thanks!


> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 00:18:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 10 Jul 2009 00:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6327) Servlet hangs in
	classloader
In-Reply-To: <11803824.1229509077422.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <409898025.1247199509429.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene resolved JBAS-6327.
-----------------------------------

    Resolution: Done


Fixed in 5.x branch

> Servlet hangs in classloader
> ----------------------------
>
>                 Key: JBAS-6327
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6327
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Testsuite ejb3/servlet
>            Reporter: Carlo de Wolf
>            Assignee: Jason T. Greene
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> "http-localhost%2F127.0.0.1-8080-1" daemon prio=1 tid=0x10ae3118 nid=0x6b36 runnable [0x7897c000..0x7897df20]
> 	at java.lang.ClassLoader.defineClass1(Native Method)
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:62)
> 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:509)
> 	at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:469)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:467)
> 	- locked <0x9a2ff1a8> (a org.jboss.classloader.spi.base.BaseClassLoader)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:444)
> 	at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
> 	at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
> 	at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
> 	at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:254)
> 	at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:148)
> 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:256)
> 	at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1099)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:735)
> 	at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:378)
> 	- locked <0x9a2ff1a8> (a org.jboss.classloader.spi.base.BaseClassLoader)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
> 	- locked <0x9a757fb8> (a org.jboss.web.tomcat.service.WebCtxLoader$ENCLoader)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> 	- locked <0x9a757fb8> (a org.jboss.web.tomcat.service.WebCtxLoader$ENCLoader)
> 	at $Proxy156.getWarTestObject(Unknown Source)
> 	at org.jboss.ejb3.test.servlet.servlets.EJBServlet.processRequest(EJBServlet.java:95)
> 	at org.jboss.ejb3.test.servlet.servlets.EJBServlet.doGet(EJBServlet.java:146)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 01:21:41 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 10 Jul 2009 01:21:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-99) Create extensible AS
 Server implementation base
Message-ID: <1375381167.1247203301607.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Create extensible AS Server implementation base
-----------------------------------------------

                 Key: JBBOOT-99
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-99
             Project: JBoss Bootstrap
          Issue Type: Task
          Components: impl-as
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 2.0.0-beta-1 


JBossASEmbeddedServerImpl in the EMB project currently extends from JBossASServerImpl, which provides no generics to allow for covarient return.  As a result, the method chaining functions come back as JBossASServer instead of JBossASEmbeddedServer.  

Make an extensible AS server implementation which keeps the generics chain alive.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 02:47:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 10 Jul 2009 02:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <83268276.1247208449203.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475694#action_12475694 ] 

Tim Fox commented on JBMESSAGING-1681:
--------------------------------------

Konstantin-

The ejb tutorial is not written or managed by the JBoss Messaging team, it's handled by the EJB3 team.

If you think it is wrong, then you can raise an issue on the EJB forum and hopefully they will correct it.

> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 04:26:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 10 Jul 2009 04:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <865530579.1247214389232.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475703#action_12475703 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

To keep the time longer, the node id has to shrink to give up more bits to time. Also we need to increase the granularity of the time bits. So I suggest the ID structure:

1) 10 bits node id (that allow node id to range from 0 to 1023).

2) 39 bits time from System.currentTimeMillis(). 

To make the time of repetition longer than 100 years using only 39 bits, we need to extract it from 4th bit to 42nd bit of the system time. So the time of repetition can be calculated as such

(2^39 - 1)/125/60/60/24/365.25   ====> about 139.36 years.

3) 15 bits counter. (range from 0 to 32767)

So the overall structure of a 64-bit ID is:

[10-bit node id][39-bit time][15-bit counter]













> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 04:28:42 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 10 Jul 2009 04:28:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <862976998.1247214522302.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475704#action_12475704 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

The TimeAndCounterIDGenerator in JBM 2.0 is not suitable for 1.4 because it doesn't use node id. We need the node id to guarantee the uniqueness across the cluster (as we use shared DB).



> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 04:39:41 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 10 Jul 2009 04:39:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1186648017.1247215181579.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475707#action_12475707 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

Hi Tim,

Can you give some comments on my latest suggestion so that I can move on? Thanks.

Howard

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 04:45:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 10 Jul 2009 04:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <153071870.1247215529347.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475708#action_12475708 ] 

Tim Fox commented on JBMESSAGING-1682:
--------------------------------------

Why don't use adapt the JBM 2.0 method to use the node id too?

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 04:48:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 04:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1857) Track the
 upgrades during EJB3 plugin 1.0.10 release
In-Reply-To: <11399327.1246000976433.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1461216001.1247215709133.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1857.
------------------------------------

                  Resolution: Done
    Component Fix Version(s): jboss-ejb3-plugin:1.0.10


> Track the upgrades during EJB3 plugin 1.0.10 release
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1857
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1857
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: plugin
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> This issue is to track any updates to version dependencies during the EJB3 1.0.10 plugin release.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 04:50:40 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 04:50:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1858) NPE if in
 resource-env-ref no injection target is specified
In-Reply-To: <15528450.1246042016731.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1415996817.1247215840375.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1858.
------------------------------------

    Fix Version/s: 1.1.9
       Resolution: Done


> NPE if in resource-env-ref no injection target is specified
> -----------------------------------------------------------
>
>                 Key: EJBTHREE-1858
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1858
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.7
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>             Fix For: 1.1.9
>
>         Attachments: ResourceEnvRefNPE.jar
>
>
> If an ENC entry for java:/comp/EJBContext is declared and NO injection target is specified, this results in a NPE.
> 			<resource-env-ref>
> 				<resource-env-ref-name>EnvNameOfSessionContext</resource-env-ref-name>
>  				<resource-env-ref-type>javax.ejb.SessionContext</resource-env-ref-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 			</resource-env-ref>
> The exception is:
> ...
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.InjectionUtil.createInjectors(InjectionUtil.java:105)
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceEnvRefs(ResourceHandler.java:227)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:343)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:597)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:434)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:543)
> 	... 69 more
> Looking at the code in ResourceHandler.loadXmlResourceEnvRefs, this is the only place where the check "if(envRef.getInjectionTargets() != null)" is missing ;-).
> I will attach a sample.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 04:59:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 04:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1854) Configure EJB3
 MC beans to avoid AOPDependencyBuilder
In-Reply-To: <16175879.1245767758566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1329489515.1247216369232.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1854:
-----------------------------------

    Component/s: proxy-impl
                     (was: deployers)


> Configure EJB3 MC beans to avoid AOPDependencyBuilder
> -----------------------------------------------------
>
>                 Key: EJBTHREE-1854
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1854
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: core, proxy-impl
>    Affects Versions: 1.1.7
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> This task is to keep track of the change(s) required for all EJB3 MC bean (programatic and xml based) to ensure that the AOPDependencyBuilder does not come into picture during deployment. Avoiding AOPDependencyBuilder has shown good performance improvements.
> There isn't a final decision yet on how to do this although MC provides @DisableAOP annotation to achieve this. The MC support for this is currently available in AS 5_x branch and needs to be ported to AS trunk before EJB3 can think of using this. Once there's a decision on what's the best approach to accomplish this, we can do the changes in EJB3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 05:03:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 10 Jul 2009 05:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <606259378.1247216609363.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475710#action_12475710 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

--- Why don't use adapt the JBM 2.0 method to use the node id too? 

If you mean TimeAndCounterIDGenerator, I don't think it would make much difference. This class uses [44 bits time] + [20 bits counter]. If we add the node id bits in, that will be the same as the existing one.

It's strange I can't find where this class is used in JBM 2.0 other than in tests. but I can't find any other class that do the job.

Howard


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 05:03:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 05:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1854) Configure EJB3
 MC beans to avoid AOPDependencyBuilder
In-Reply-To: <16175879.1245767758566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2029387919.1247216609260.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1854.
------------------------------------

               Fix Version/s: 1.1.9
                  Resolution: Done
    Component Fix Version(s): jboss-ejb3-core:1.1.9 jboss-ejb3-proxy-impl:1.0.3


The EJB3 containers and the proxy factories which are registed as MC beans, now use @DisableAOP. Furthermore, the EJB3 MC bean configuration xmls have also been updated to use this annotation.


> Configure EJB3 MC beans to avoid AOPDependencyBuilder
> -----------------------------------------------------
>
>                 Key: EJBTHREE-1854
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1854
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: core, proxy-impl
>    Affects Versions: 1.1.7
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 1.1.9
>
>
> This task is to keep track of the change(s) required for all EJB3 MC bean (programatic and xml based) to ensure that the AOPDependencyBuilder does not come into picture during deployment. Avoiding AOPDependencyBuilder has shown good performance improvements.
> There isn't a final decision yet on how to do this although MC provides @DisableAOP annotation to achieve this. The MC support for this is currently available in AS 5_x branch and needs to be ported to AS trunk before EJB3 can think of using this. Once there's a decision on what's the best approach to accomplish this, we can do the changes in EJB3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 05:05:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 10 Jul 2009 05:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1184395753.1247216729288.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475711#action_12475711 ] 

Tim Fox commented on JBMESSAGING-1682:
--------------------------------------

You're looking at the wrong class, the correct one is JournalStorageManagerImpl.BatchingIDGenerator

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 05:09:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 05:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1861) Upgrade
 microcontainer to 2.0.8.GA
In-Reply-To: <2037967472.1246535944178.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1826127143.1247216969135.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1861:
-----------------------------------

    Component/s: build


> Upgrade microcontainer to 2.0.8.GA
> ----------------------------------
>
>                 Key: EJBTHREE-1861
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1861
>             Project: EJB 3.0
>          Issue Type: Thirdparty Change
>          Components: build
>    Affects Versions: 1.1.8
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> In order to be able to use the @DisableAOP feature in MC, we need to upgrade to this latest version of MC. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 05:26:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 05:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1861) Upgrade
 microcontainer to 2.0.8.GA
In-Reply-To: <2037967472.1246535944178.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1448282406.1247217989111.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1861.
------------------------------------

               Fix Version/s: 1.1.9
                  Resolution: Done
    Component Fix Version(s): jboss-ejb3-build:1.0.4


> Upgrade microcontainer to 2.0.8.GA
> ----------------------------------
>
>                 Key: EJBTHREE-1861
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1861
>             Project: EJB 3.0
>          Issue Type: Thirdparty Change
>          Components: build
>    Affects Versions: 1.1.8
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 1.1.9
>
>
> In order to be able to use the @DisableAOP feature in MC, we need to upgrade to this latest version of MC. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 05:28:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 05:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1858) NPE if in
 resource-env-ref no injection target is specified
In-Reply-To: <15528450.1246042016731.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1811300737.1247218109324.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1858:
-----------------------------------

    Component/s: core


> NPE if in resource-env-ref no injection target is specified
> -----------------------------------------------------------
>
>                 Key: EJBTHREE-1858
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1858
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.7
>            Reporter: Wolfgang Knauf
>            Assignee: jaikiran pai
>             Fix For: 1.1.9
>
>         Attachments: ResourceEnvRefNPE.jar
>
>
> If an ENC entry for java:/comp/EJBContext is declared and NO injection target is specified, this results in a NPE.
> 			<resource-env-ref>
> 				<resource-env-ref-name>EnvNameOfSessionContext</resource-env-ref-name>
>  				<resource-env-ref-type>javax.ejb.SessionContext</resource-env-ref-type>
> 				<mapped-name>java:comp/EJBContext</mapped-name>
> 			</resource-env-ref>
> The exception is:
> ...
> Caused by: java.lang.NullPointerException
> 	at org.jboss.injection.InjectionUtil.createInjectors(InjectionUtil.java:105)
> 	at org.jboss.injection.ResourceHandler.loadXmlResourceEnvRefs(ResourceHandler.java:227)
> 	at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:343)
> 	at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:597)
> 	at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:434)
> 	at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:543)
> 	... 69 more
> Looking at the code in ResourceHandler.loadXmlResourceEnvRefs, this is the only place where the check "if(envRef.getInjectionTargets() != null)" is missing ;-).
> I will attach a sample.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 05:34:42 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 10 Jul 2009 05:34:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <332247889.1247218482838.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475712#action_12475712 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

Thanks Tim, I had a look at it and I think the idea is to drop the time bits and use check points.

So the idea would be:

[10 bits node-id][54 bits counter]

This eliminates the time issue. But we need:

create a table in the DB, store checkpoints for each node.

It looks like a simple solution, I'll try this way. 

Comments?

Howard


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 05:42:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 05:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1867) Track the
 upgrades during EJB3 plugin 1.0.11 release
Message-ID: <260824002.1247218949130.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Track the upgrades during EJB3 plugin 1.0.11 release
----------------------------------------------------

                 Key: EJBTHREE-1867
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1867
             Project: EJB 3.0
          Issue Type: Task
          Components: plugin
            Reporter: jaikiran pai
            Assignee: jaikiran pai


This JIRA will track the dependency upgrades during the release of EJB3 plugin 1.0.11

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 06:21:29 2009
From: jira-events at lists.jboss.org (Christian Spurk (JIRA))
Date: Fri, 10 Jul 2009 06:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2203)
 NullPointerException When
 Using Conditional Element "or" in LHS Together with a Return Value
 Restriction
In-Reply-To: <1905551867.1247221071455.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1188629659.1247221289321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Spurk updated JBRULES-2203:
-------------------------------------

    Description: 
When using the conditional element "or" on the left hand side of a rule together with a return value restriction somewhere in the same rule, I get the following exception:

{quote}
Exception in thread "main" java.lang.NullPointerException
	at org.drools.rule.ReturnValueRestriction.equals(ReturnValueRestriction.java:304)
	at org.drools.rule.ReturnValueConstraint.equals(ReturnValueConstraint.java:121)
	at org.drools.reteoo.AlphaNode.equals(AlphaNode.java:218)
	at org.drools.reteoo.SingleObjectSinkAdapter.getMatchingNode(SingleObjectSinkAdapter.java:48)
	at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:130)
	at org.drools.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:295)
	at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:117)
	at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:70)
	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:126)
	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:73)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:153)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:126)
	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:362)
	at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:618)
	at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:500)
	at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:379)
	at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:121)
	at com.sample.DroolsTest.readKnowledgeBase(DroolsTest.java:48)
	at com.sample.DroolsTest.main(DroolsTest.java:26)
{quote}

Here is a simple test case which can be used to reproduce the issue:

{code}
/* JAVA FILE TO LOAD THE RULE */
package com.sample;

import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderError;
import org.drools.builder.KnowledgeBuilderErrors;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.builder.ResourceType;
import org.drools.io.ResourceFactory;
import org.drools.runtime.StatefulKnowledgeSession;

public class DroolsTest {

	private int arg;

	public int getArg() {
		return this.arg;
	}

	public void setArg(int arg) {
		this.arg = arg;
	}

	public static final void main(String[] args) throws Exception {
		KnowledgeBase kbase = readKnowledgeBase();
		StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

		DroolsTest test = new DroolsTest();
		test.setArg(2);
		ksession.insert(test);

		ksession.fireAllRules();
	}

	/* taken verbatim from the Hello World sample */
	private static KnowledgeBase readKnowledgeBase() throws Exception {
		KnowledgeBuilder kbuilder = KnowledgeBuilderFactory
				.newKnowledgeBuilder();
		kbuilder.add(ResourceFactory.newClassPathResource("Sample.drl"),
				ResourceType.DRL);
		KnowledgeBuilderErrors errors = kbuilder.getErrors();
		if (errors.size() > 0) {
			for (KnowledgeBuilderError error : errors) {
				System.err.println(error);
			}
			throw new IllegalArgumentException("Could not parse knowledge.");
		}
		KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
		kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
		return kbase;
	}

}
{code}


{code}
/* PROBLEMATIC RULE FILE */
package com.sample
 
import com.sample.DroolsTest;

rule "test"
	when
		DroolsTest( arg == (1 + 1) );
		// REMOVE THE COMMENTED PARTS BELOW TO GET THE EXCEPTION:
		//(or	eval(true);
			eval(true);
		//)
	then
		System.out.println( "it works!" );
end
{code}


When the above Java file is compiled and run in combination with the given rule file, everything works fine. However, if the marked parts of the rule are uncommented, then you get the exception.

PS: It seems that the issue has been existing in previous Drools versions already, see https://jira.jboss.org/jira/browse/JBSEAM-3064 for example ("Drools 4.0.7 don't like 'action == (DocumentType.USER.extendedName())' and multiple OR's - weird!").


  was:
When using the conditional element "or" on the left hand side of a rule together with a return value restriction somewhere in the same rule, I get the following exception:

Exception in thread "main" java.lang.NullPointerException
	at org.drools.rule.ReturnValueRestriction.equals(ReturnValueRestriction.java:304)
	at org.drools.rule.ReturnValueConstraint.equals(ReturnValueConstraint.java:121)
	at org.drools.reteoo.AlphaNode.equals(AlphaNode.java:218)
	at org.drools.reteoo.SingleObjectSinkAdapter.getMatchingNode(SingleObjectSinkAdapter.java:48)
	at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:130)
	at org.drools.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:295)
	at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:117)
	at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:70)
	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:126)
	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:73)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:153)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:126)
	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:362)
	at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:618)
	at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:500)
	at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:379)
	at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:121)
	at com.sample.DroolsTest.readKnowledgeBase(DroolsTest.java:48)
	at com.sample.DroolsTest.main(DroolsTest.java:26)

Here is a simple test case which can be used to reproduce the issue:

/* JAVA FILE TO LOAD THE RULE */
package com.sample;

import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderError;
import org.drools.builder.KnowledgeBuilderErrors;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.builder.ResourceType;
import org.drools.io.ResourceFactory;
import org.drools.runtime.StatefulKnowledgeSession;

public class DroolsTest {

	private int arg;

	public int getArg() {
		return this.arg;
	}

	public void setArg(int arg) {
		this.arg = arg;
	}

	public static final void main(String[] args) throws Exception {
		KnowledgeBase kbase = readKnowledgeBase();
		StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

		DroolsTest test = new DroolsTest();
		test.setArg(2);
		ksession.insert(test);

		ksession.fireAllRules();
	}

	/* taken verbatim from the Hello World sample */
	private static KnowledgeBase readKnowledgeBase() throws Exception {
		KnowledgeBuilder kbuilder = KnowledgeBuilderFactory
				.newKnowledgeBuilder();
		kbuilder.add(ResourceFactory.newClassPathResource("Sample.drl"),
				ResourceType.DRL);
		KnowledgeBuilderErrors errors = kbuilder.getErrors();
		if (errors.size() > 0) {
			for (KnowledgeBuilderError error : errors) {
				System.err.println(error);
			}
			throw new IllegalArgumentException("Could not parse knowledge.");
		}
		KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
		kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
		return kbase;
	}

}


/* PROBLEMATIC RULE FILE */
package com.sample
 
import com.sample.DroolsTest;

rule "test"
	when
		DroolsTest( arg == (1 + 1) );
		// REMOVE THE COMMENTED PARTS BELOW TO GET THE EXCEPTION:
		//(or	eval(true);
			eval(true);
		//)
	then
		System.out.println( "it works!" );
end


When the above Java file is compiled and run in combination with the given rule file, everything works fine. However, if the marked parts of the rule are uncommented, then you get the exception.

PS: It seems that the issue has been existing in previous Drools versions already, see https://jira.jboss.org/jira/browse/JBSEAM-3064 for example ("Drools 4.0.7 don't like 'action == (DocumentType.USER.extendedName())' and multiple OR's - weird!").




> NullPointerException When Using Conditional Element "or" in LHS Together with a Return Value Restriction
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2203
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2203
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (expert)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Drools 5.0.1 used in an Eclipse Drools project under Windows XP with Java 1.6
>            Reporter: Christian Spurk
>            Assignee: Mark Proctor
>
> When using the conditional element "or" on the left hand side of a rule together with a return value restriction somewhere in the same rule, I get the following exception:
> {quote}
> Exception in thread "main" java.lang.NullPointerException
> 	at org.drools.rule.ReturnValueRestriction.equals(ReturnValueRestriction.java:304)
> 	at org.drools.rule.ReturnValueConstraint.equals(ReturnValueConstraint.java:121)
> 	at org.drools.reteoo.AlphaNode.equals(AlphaNode.java:218)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.getMatchingNode(SingleObjectSinkAdapter.java:48)
> 	at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:130)
> 	at org.drools.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:295)
> 	at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:117)
> 	at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:70)
> 	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:126)
> 	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:73)
> 	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:153)
> 	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:126)
> 	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
> 	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:362)
> 	at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:618)
> 	at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:500)
> 	at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:379)
> 	at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:121)
> 	at com.sample.DroolsTest.readKnowledgeBase(DroolsTest.java:48)
> 	at com.sample.DroolsTest.main(DroolsTest.java:26)
> {quote}
> Here is a simple test case which can be used to reproduce the issue:
> {code}
> /* JAVA FILE TO LOAD THE RULE */
> package com.sample;
> import org.drools.KnowledgeBase;
> import org.drools.KnowledgeBaseFactory;
> import org.drools.builder.KnowledgeBuilder;
> import org.drools.builder.KnowledgeBuilderError;
> import org.drools.builder.KnowledgeBuilderErrors;
> import org.drools.builder.KnowledgeBuilderFactory;
> import org.drools.builder.ResourceType;
> import org.drools.io.ResourceFactory;
> import org.drools.runtime.StatefulKnowledgeSession;
> public class DroolsTest {
> 	private int arg;
> 	public int getArg() {
> 		return this.arg;
> 	}
> 	public void setArg(int arg) {
> 		this.arg = arg;
> 	}
> 	public static final void main(String[] args) throws Exception {
> 		KnowledgeBase kbase = readKnowledgeBase();
> 		StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
> 		DroolsTest test = new DroolsTest();
> 		test.setArg(2);
> 		ksession.insert(test);
> 		ksession.fireAllRules();
> 	}
> 	/* taken verbatim from the Hello World sample */
> 	private static KnowledgeBase readKnowledgeBase() throws Exception {
> 		KnowledgeBuilder kbuilder = KnowledgeBuilderFactory
> 				.newKnowledgeBuilder();
> 		kbuilder.add(ResourceFactory.newClassPathResource("Sample.drl"),
> 				ResourceType.DRL);
> 		KnowledgeBuilderErrors errors = kbuilder.getErrors();
> 		if (errors.size() > 0) {
> 			for (KnowledgeBuilderError error : errors) {
> 				System.err.println(error);
> 			}
> 			throw new IllegalArgumentException("Could not parse knowledge.");
> 		}
> 		KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
> 		kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
> 		return kbase;
> 	}
> }
> {code}
> {code}
> /* PROBLEMATIC RULE FILE */
> package com.sample
>  
> import com.sample.DroolsTest;
> rule "test"
> 	when
> 		DroolsTest( arg == (1 + 1) );
> 		// REMOVE THE COMMENTED PARTS BELOW TO GET THE EXCEPTION:
> 		//(or	eval(true);
> 			eval(true);
> 		//)
> 	then
> 		System.out.println( "it works!" );
> end
> {code}
> When the above Java file is compiled and run in combination with the given rule file, everything works fine. However, if the marked parts of the rule are uncommented, then you get the exception.
> PS: It seems that the issue has been existing in previous Drools versions already, see https://jira.jboss.org/jira/browse/JBSEAM-3064 for example ("Drools 4.0.7 don't like 'action == (DocumentType.USER.extendedName())' and multiple OR's - weird!").

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 06:23:29 2009
From: jira-events at lists.jboss.org (Christian Spurk (JIRA))
Date: Fri, 10 Jul 2009 06:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2203)
 NullPointerException When
 Using Conditional Element "or" in LHS Together with a Return Value
 Restriction
In-Reply-To: <1905551867.1247221071455.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <645657579.1247221409336.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Spurk updated JBRULES-2203:
-------------------------------------

    Description: 
When using the conditional element "or" on the left hand side of a rule together with a return value restriction somewhere in the same rule, I get the following exception:


Exception in thread "main" java.lang.NullPointerException
	at org.drools.rule.ReturnValueRestriction.equals(ReturnValueRestriction.java:304)
	at org.drools.rule.ReturnValueConstraint.equals(ReturnValueConstraint.java:121)
	at org.drools.reteoo.AlphaNode.equals(AlphaNode.java:218)
	at org.drools.reteoo.SingleObjectSinkAdapter.getMatchingNode(SingleObjectSinkAdapter.java:48)
	at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:130)
	at org.drools.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:295)
	at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:117)
	at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:70)
	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:126)
	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:73)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:153)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:126)
	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:362)
	at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:618)
	at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:500)
	at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:379)
	at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:121)
	at com.sample.DroolsTest.readKnowledgeBase(DroolsTest.java:48)
	at com.sample.DroolsTest.main(DroolsTest.java:26)


Here is a simple test case which can be used to reproduce the issue:


/* JAVA FILE TO LOAD THE RULE */
package com.sample;

import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderError;
import org.drools.builder.KnowledgeBuilderErrors;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.builder.ResourceType;
import org.drools.io.ResourceFactory;
import org.drools.runtime.StatefulKnowledgeSession;

public class DroolsTest {

	private int arg;

	public int getArg() {
		return this.arg;
	}

	public void setArg(int arg) {
		this.arg = arg;
	}

	public static final void main(String[] args) throws Exception {
		KnowledgeBase kbase = readKnowledgeBase();
		StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

		DroolsTest test = new DroolsTest();
		test.setArg(2);
		ksession.insert(test);

		ksession.fireAllRules();
	}

	/* taken verbatim from the Hello World sample */
	private static KnowledgeBase readKnowledgeBase() throws Exception {
		KnowledgeBuilder kbuilder = KnowledgeBuilderFactory
				.newKnowledgeBuilder();
		kbuilder.add(ResourceFactory.newClassPathResource("Sample.drl"),
				ResourceType.DRL);
		KnowledgeBuilderErrors errors = kbuilder.getErrors();
		if (errors.size() > 0) {
			for (KnowledgeBuilderError error : errors) {
				System.err.println(error);
			}
			throw new IllegalArgumentException("Could not parse knowledge.");
		}
		KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
		kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
		return kbase;
	}

}




/* PROBLEMATIC RULE FILE */
package com.sample
 
import com.sample.DroolsTest;

rule "test"
	when
		DroolsTest( arg == (1 + 1) );
		// REMOVE THE COMMENTED PARTS BELOW TO GET THE EXCEPTION:
		//(or	eval(true);
			eval(true);
		//)
	then
		System.out.println( "it works!" );
end


When the above Java file is compiled and run in combination with the given rule file, everything works fine. However, if the marked parts of the rule are uncommented, then you get the exception.

PS: It seems that the issue has been existing in previous Drools versions already, see https://jira.jboss.org/jira/browse/JBSEAM-3064 for example ("Drools 4.0.7 don't like 'action == (DocumentType.USER.extendedName())' and multiple OR's - weird!").


  was:
When using the conditional element "or" on the left hand side of a rule together with a return value restriction somewhere in the same rule, I get the following exception:

{quote}
Exception in thread "main" java.lang.NullPointerException
	at org.drools.rule.ReturnValueRestriction.equals(ReturnValueRestriction.java:304)
	at org.drools.rule.ReturnValueConstraint.equals(ReturnValueConstraint.java:121)
	at org.drools.reteoo.AlphaNode.equals(AlphaNode.java:218)
	at org.drools.reteoo.SingleObjectSinkAdapter.getMatchingNode(SingleObjectSinkAdapter.java:48)
	at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:130)
	at org.drools.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:295)
	at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:117)
	at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:70)
	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:126)
	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:73)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:153)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:126)
	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:362)
	at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:618)
	at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:500)
	at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:379)
	at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:121)
	at com.sample.DroolsTest.readKnowledgeBase(DroolsTest.java:48)
	at com.sample.DroolsTest.main(DroolsTest.java:26)
{quote}

Here is a simple test case which can be used to reproduce the issue:

{code}
/* JAVA FILE TO LOAD THE RULE */
package com.sample;

import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderError;
import org.drools.builder.KnowledgeBuilderErrors;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.builder.ResourceType;
import org.drools.io.ResourceFactory;
import org.drools.runtime.StatefulKnowledgeSession;

public class DroolsTest {

	private int arg;

	public int getArg() {
		return this.arg;
	}

	public void setArg(int arg) {
		this.arg = arg;
	}

	public static final void main(String[] args) throws Exception {
		KnowledgeBase kbase = readKnowledgeBase();
		StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

		DroolsTest test = new DroolsTest();
		test.setArg(2);
		ksession.insert(test);

		ksession.fireAllRules();
	}

	/* taken verbatim from the Hello World sample */
	private static KnowledgeBase readKnowledgeBase() throws Exception {
		KnowledgeBuilder kbuilder = KnowledgeBuilderFactory
				.newKnowledgeBuilder();
		kbuilder.add(ResourceFactory.newClassPathResource("Sample.drl"),
				ResourceType.DRL);
		KnowledgeBuilderErrors errors = kbuilder.getErrors();
		if (errors.size() > 0) {
			for (KnowledgeBuilderError error : errors) {
				System.err.println(error);
			}
			throw new IllegalArgumentException("Could not parse knowledge.");
		}
		KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
		kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
		return kbase;
	}

}
{code}


{code}
/* PROBLEMATIC RULE FILE */
package com.sample
 
import com.sample.DroolsTest;

rule "test"
	when
		DroolsTest( arg == (1 + 1) );
		// REMOVE THE COMMENTED PARTS BELOW TO GET THE EXCEPTION:
		//(or	eval(true);
			eval(true);
		//)
	then
		System.out.println( "it works!" );
end
{code}


When the above Java file is compiled and run in combination with the given rule file, everything works fine. However, if the marked parts of the rule are uncommented, then you get the exception.

PS: It seems that the issue has been existing in previous Drools versions already, see https://jira.jboss.org/jira/browse/JBSEAM-3064 for example ("Drools 4.0.7 don't like 'action == (DocumentType.USER.extendedName())' and multiple OR's - weird!").




> NullPointerException When Using Conditional Element "or" in LHS Together with a Return Value Restriction
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2203
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2203
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (expert)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Drools 5.0.1 used in an Eclipse Drools project under Windows XP with Java 1.6
>            Reporter: Christian Spurk
>            Assignee: Mark Proctor
>
> When using the conditional element "or" on the left hand side of a rule together with a return value restriction somewhere in the same rule, I get the following exception:
> Exception in thread "main" java.lang.NullPointerException
> 	at org.drools.rule.ReturnValueRestriction.equals(ReturnValueRestriction.java:304)
> 	at org.drools.rule.ReturnValueConstraint.equals(ReturnValueConstraint.java:121)
> 	at org.drools.reteoo.AlphaNode.equals(AlphaNode.java:218)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.getMatchingNode(SingleObjectSinkAdapter.java:48)
> 	at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:130)
> 	at org.drools.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:295)
> 	at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:117)
> 	at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:70)
> 	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:126)
> 	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:73)
> 	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:153)
> 	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:126)
> 	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
> 	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:362)
> 	at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:618)
> 	at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:500)
> 	at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:379)
> 	at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:121)
> 	at com.sample.DroolsTest.readKnowledgeBase(DroolsTest.java:48)
> 	at com.sample.DroolsTest.main(DroolsTest.java:26)
> Here is a simple test case which can be used to reproduce the issue:
> /* JAVA FILE TO LOAD THE RULE */
> package com.sample;
> import org.drools.KnowledgeBase;
> import org.drools.KnowledgeBaseFactory;
> import org.drools.builder.KnowledgeBuilder;
> import org.drools.builder.KnowledgeBuilderError;
> import org.drools.builder.KnowledgeBuilderErrors;
> import org.drools.builder.KnowledgeBuilderFactory;
> import org.drools.builder.ResourceType;
> import org.drools.io.ResourceFactory;
> import org.drools.runtime.StatefulKnowledgeSession;
> public class DroolsTest {
> 	private int arg;
> 	public int getArg() {
> 		return this.arg;
> 	}
> 	public void setArg(int arg) {
> 		this.arg = arg;
> 	}
> 	public static final void main(String[] args) throws Exception {
> 		KnowledgeBase kbase = readKnowledgeBase();
> 		StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
> 		DroolsTest test = new DroolsTest();
> 		test.setArg(2);
> 		ksession.insert(test);
> 		ksession.fireAllRules();
> 	}
> 	/* taken verbatim from the Hello World sample */
> 	private static KnowledgeBase readKnowledgeBase() throws Exception {
> 		KnowledgeBuilder kbuilder = KnowledgeBuilderFactory
> 				.newKnowledgeBuilder();
> 		kbuilder.add(ResourceFactory.newClassPathResource("Sample.drl"),
> 				ResourceType.DRL);
> 		KnowledgeBuilderErrors errors = kbuilder.getErrors();
> 		if (errors.size() > 0) {
> 			for (KnowledgeBuilderError error : errors) {
> 				System.err.println(error);
> 			}
> 			throw new IllegalArgumentException("Could not parse knowledge.");
> 		}
> 		KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
> 		kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
> 		return kbase;
> 	}
> }
> /* PROBLEMATIC RULE FILE */
> package com.sample
>  
> import com.sample.DroolsTest;
> rule "test"
> 	when
> 		DroolsTest( arg == (1 + 1) );
> 		// REMOVE THE COMMENTED PARTS BELOW TO GET THE EXCEPTION:
> 		//(or	eval(true);
> 			eval(true);
> 		//)
> 	then
> 		System.out.println( "it works!" );
> end
> When the above Java file is compiled and run in combination with the given rule file, everything works fine. However, if the marked parts of the rule are uncommented, then you get the exception.
> PS: It seems that the issue has been existing in previous Drools versions already, see https://jira.jboss.org/jira/browse/JBSEAM-3064 for example ("Drools 4.0.7 don't like 'action == (DocumentType.USER.extendedName())' and multiple OR's - weird!").

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 07:45:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 10 Jul 2009 07:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <678469498.1247226329256.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475718#action_12475718 ] 

Tim Fox commented on JBMESSAGING-1682:
--------------------------------------

Bear in mind you may not be able to make database changes on a CP release

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 07:51:29 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 10 Jul 2009 07:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <781028316.1247226689638.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475719#action_12475719 ] 

Scott Marlow commented on JBAS-6185:
------------------------------------

I verified that both ideas from Mike Van Noord do resolve the issue (jconsole will work with both jdk 5 + 6).  

> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Scott Marlow
>            Priority: Blocker
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 08:30:42 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 10 Jul 2009 08:30:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1266948613.1247229042279.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475725#action_12475725 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

yeah, DB change seems not like a good idea. 


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 08:45:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 10 Jul 2009 08:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1129931268.1247229929350.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475728#action_12475728 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

I think I'll go back to my previous way, 
[10-bit node id][39-bit time][15-bit counter] 

This reduces the node id range from 65535 to 1023. It's not likely that there exists a single cluster of size larger than 1024 nodes.


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 08:52:40 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 10 Jul 2009 08:52:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <835486024.1247230360717.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475729#action_12475729 ] 

Tim Fox commented on JBMESSAGING-1682:
--------------------------------------

If you use 39 bits from the time but only take from the 4th bit, then you will only be able to create a maximum of
2^16/2^4 = 2^12 = 4096 ids per millisecond before overlap

=4096000. hopefully should be enough for JBM 1.x

make sure you change the logic that checks for counter overlap since right now it's assumes 1 millisecond precision

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 09:07:29 2009
From: jira-events at lists.jboss.org (anil kumar (JIRA))
Date: Fri, 10 Jul 2009 09:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7093) communitcation from
 scriptlet to jsf managed bean is not working
Message-ID: <404200839.1247231249370.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

communitcation from scriptlet to jsf managed bean is not working
----------------------------------------------------------------

                 Key: JBAS-7093
                 URL: https://jira.jboss.org/jira/browse/JBAS-7093
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JSF
    Affects Versions: JBossAS-5.1.0.GA
         Environment: windows
            Reporter: anil kumar
            Assignee: Stan Silvert



Here is the sample code.
   <%
                    
            for (int i = 1; i < 5; i++) {
                HeaderBean header = new HeaderBean();
                header.setScreenID("" + i);
                application.setAttribute("HeaderBean", header);
               %>                                     
                    
                <h:outputText  value="#{HeaderBean.screenID}"> </h:outputText> 	
                    
 <%}%>        

its always displaying the last value,the out put is "4444" instead of "1234". Is this expected behavior?



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 09:09:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 10 Jul 2009 09:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1682) duplicate
 key value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <718533783.1247231369211.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475735#action_12475735 ] 

Howard Gao commented on JBMESSAGING-1682:
-----------------------------------------

yes you are right, about 4 million a second for a single node.

I'll be careful about the logic. Thanks.



> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 06:17:51 2009
From: jira-events at lists.jboss.org (Christian Spurk (JIRA))
Date: Fri, 10 Jul 2009 06:17:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2203)
 NullPointerException When
 Using Conditional Element "or" in LHS Together with a Return Value
 Restriction
Message-ID: <1905551867.1247221071455.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

NullPointerException When Using Conditional Element "or" in LHS Together with a Return Value Restriction
--------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2203
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2203
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler (expert)
    Affects Versions: 5.0.1.FINAL
         Environment: Drools 5.0.1 used in an Eclipse Drools project under Windows XP with Java 1.6
            Reporter: Christian Spurk
            Assignee: Mark Proctor


When using the conditional element "or" on the left hand side of a rule together with a return value restriction somewhere in the same rule, I get the following exception:

Exception in thread "main" java.lang.NullPointerException
	at org.drools.rule.ReturnValueRestriction.equals(ReturnValueRestriction.java:304)
	at org.drools.rule.ReturnValueConstraint.equals(ReturnValueConstraint.java:121)
	at org.drools.reteoo.AlphaNode.equals(AlphaNode.java:218)
	at org.drools.reteoo.SingleObjectSinkAdapter.getMatchingNode(SingleObjectSinkAdapter.java:48)
	at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:130)
	at org.drools.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:295)
	at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:117)
	at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:70)
	at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:126)
	at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:73)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:153)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:126)
	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:362)
	at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:618)
	at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:500)
	at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:379)
	at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:121)
	at com.sample.DroolsTest.readKnowledgeBase(DroolsTest.java:48)
	at com.sample.DroolsTest.main(DroolsTest.java:26)

Here is a simple test case which can be used to reproduce the issue:

/* JAVA FILE TO LOAD THE RULE */
package com.sample;

import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderError;
import org.drools.builder.KnowledgeBuilderErrors;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.builder.ResourceType;
import org.drools.io.ResourceFactory;
import org.drools.runtime.StatefulKnowledgeSession;

public class DroolsTest {

	private int arg;

	public int getArg() {
		return this.arg;
	}

	public void setArg(int arg) {
		this.arg = arg;
	}

	public static final void main(String[] args) throws Exception {
		KnowledgeBase kbase = readKnowledgeBase();
		StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

		DroolsTest test = new DroolsTest();
		test.setArg(2);
		ksession.insert(test);

		ksession.fireAllRules();
	}

	/* taken verbatim from the Hello World sample */
	private static KnowledgeBase readKnowledgeBase() throws Exception {
		KnowledgeBuilder kbuilder = KnowledgeBuilderFactory
				.newKnowledgeBuilder();
		kbuilder.add(ResourceFactory.newClassPathResource("Sample.drl"),
				ResourceType.DRL);
		KnowledgeBuilderErrors errors = kbuilder.getErrors();
		if (errors.size() > 0) {
			for (KnowledgeBuilderError error : errors) {
				System.err.println(error);
			}
			throw new IllegalArgumentException("Could not parse knowledge.");
		}
		KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
		kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
		return kbase;
	}

}


/* PROBLEMATIC RULE FILE */
package com.sample
 
import com.sample.DroolsTest;

rule "test"
	when
		DroolsTest( arg == (1 + 1) );
		// REMOVE THE COMMENTED PARTS BELOW TO GET THE EXCEPTION:
		//(or	eval(true);
			eval(true);
		//)
	then
		System.out.println( "it works!" );
end


When the above Java file is compiled and run in combination with the given rule file, everything works fine. However, if the marked parts of the rule are uncommented, then you get the exception.

PS: It seems that the issue has been existing in previous Drools versions already, see https://jira.jboss.org/jira/browse/JBSEAM-3064 for example ("Drools 4.0.7 don't like 'action == (DocumentType.USER.extendedName())' and multiple OR's - weird!").


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 09:13:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Fri, 10 Jul 2009 09:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7093) communitcation from
 scriptlet to jsf managed bean is not working
In-Reply-To: <404200839.1247231249370.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <70412642.1247231609238.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert resolved JBAS-7093.
--------------------------------

    Resolution: Rejected


Anil,

Jira is for bug reports.  You should ask user questions in the forums.

Stan

> communitcation from scriptlet to jsf managed bean is not working
> ----------------------------------------------------------------
>
>                 Key: JBAS-7093
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7093
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: windows
>            Reporter: anil kumar
>            Assignee: Stan Silvert
>
> Here is the sample code.
>    <%
>                     
>             for (int i = 1; i < 5; i++) {
>                 HeaderBean header = new HeaderBean();
>                 header.setScreenID("" + i);
>                 application.setAttribute("HeaderBean", header);
>                %>                                     
>                     
>                 <h:outputText  value="#{HeaderBean.screenID}"> </h:outputText> 	
>                     
>  <%}%>        
> its always displaying the last value,the out put is "4444" instead of "1234". Is this expected behavior?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 08:30:42 2009
From: jira-events at lists.jboss.org (Michal Rorat (JIRA))
Date: Fri, 10 Jul 2009 08:30:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7092) Server fails to
 deploy war files in ear.
Message-ID: <775540505.1247229042120.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Server fails to deploy war files in ear.
----------------------------------------

                 Key: JBAS-7092
                 URL: https://jira.jboss.org/jira/browse/JBAS-7092
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Deployers
    Affects Versions: JBossAS-4.2.3.GA
         Environment: Windows XP 32 bit
Windows 2003 Server
            Reporter: Michal Rorat
            Assignee: Ales Justin


I have an ear file which contains ejbs and wars. It started to fail when I added sars. The problem is, it doesn't matter what wars I'm deploying, its always the second one and nothing gets deployed after this exception.

aplication.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:application="http://java.sun.com/xml/ns/javaee/application_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd" id="Application_ID" version="5">
  <module>
    <java>OracleQueue.sar</java>
  </module>
  <module>
    <java>SONController.sar</java>
  </module>
  <module>
    <ejb>Admin.jar</ejb>
  </module>
  <module>
    <ejb>Settings.jar</ejb>
  </module>
  <module>
    <ejb>Layer3Msg.jar</ejb>
  </module>
  <module>
    <java>Layer3MsgLoader.sar</java>
  </module>
  <module>
    <ejb>Layer3MsgMdb.jar</ejb>
  </module>
  <module>
    <ejb>Common.jar</ejb>
  </module>
  <module>
    <ejb>Attributes.jar</ejb>
  </module>
  <module>
    <ejb>Data.jar</ejb>
  </module>
  <module>
    <ejb>Model.jar</ejb>
  </module>
  <module>
    <ejb>Users.jar</ejb>
  </module>
  <module>
    <ejb>Tasks.jar</ejb>
  </module>
  <module>
    <ejb>Survey.jar</ejb>
  </module>
  <module>
    <ejb>BenchmarkQpis.jar</ejb>
  </module>
  <module>
    <ejb>Cellrefutils.jar</ejb>
  </module>
  <module>
    <ejb>ConfigChanges.jar</ejb>
  </module>
  <module>
    <ejb>Engine.jar</ejb>
  </module>
  <module>
    <ejb>Events.jar</ejb>
  </module>
  <module>
    <ejb>QueryDefs.jar</ejb>
  </module>
  <module>
    <ejb>QueryData.jar</ejb>
  </module>
  <module>
    <ejb>GeoTagging.jar</ejb>
  </module>
  <module>
    <ejb>Kpievents.jar</ejb>
  </module>
  <module>
    <ejb>Modules.jar</ejb>
  </module>
  <module>
    <ejb>Network.jar</ejb>
  </module>
  <module>
    <ejb>Qpis.jar</ejb>
  </module>
  <module>
    <ejb>RadioNetworkAnalysis.jar</ejb>
  </module>
  <module>
    <ejb>VirtualEarth.jar</ejb>
  </module>
  <module>
    <ejb>WMS.jar</ejb>
  </module>
  <module>
    <ejb>ReportData.jar</ejb>
  </module>
  <module>
    <ejb>ReportsMetadata.jar</ejb>
  </module>
  <module>
    <ejb>ReportProducer.jar</ejb>
  </module>
  <module>
    <web>
      <web-uri>Quorre.war</web-uri>
      <context-root>ActixOne/Quorre</context-root>
    </web>
  </module>
  <module>
    <web>
      <web-uri>TestWar.war</web-uri>
      <context-root>TestWar</context-root>
    </web>
  </module>
  <module>
    <web>
      <web-uri>Download.war</web-uri>
      <context-root>ActixOne/Download</context-root>
    </web>
  </module>
</application>

Exception:

2009-07-10 12:28:30,687 INFO  [org.jboss.ejb3.EJB3Deployer] Deployed: file:/C:/jboss-4.2/server/default/tmp/deploy/tmp4660403835223254272ActixOne.ear-contents/ReportProducer.jar
2009-07-10 12:28:30,687 INFO  [org.jboss.web.tomcat.service.TomcatDeployer] deploy, ctxPath=/ActixOne/Quorre, warUrl=.../tmp/deploy/tmp4660403835223254272ActixOne.ear-contents/Quorre-exp.war/
2009-07-10 12:28:30,875 INFO  [org.rhq.helpers.rtfilter.filter.RtFilter] Initialized response-time filter for webapp with context root 'ActixOne/Quorre'.
2009-07-10 12:28:31,687 INFO  [org.jboss.web.tomcat.service.TomcatDeployer] deploy, ctxPath=/TestWar, warUrl=.../tmp/deploy/tmp4660403835223254272ActixOne.ear-contents/TestWar-exp.war/
2009-07-10 12:28:31,687 WARN  [org.jboss.system.ServiceController] Problem starting service jboss.web.deployment:war=TestWar.war,id=2043149425
org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)
	at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:384)
	at org.jboss.web.WebModule.startModule(WebModule.java:83)
	at org.jboss.web.WebModule.startService(WebModule.java:61)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
	at $Proxy0.start(Unknown Source)
	at org.jboss.system.ServiceController.start(ServiceController.java:417)
	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.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 $Proxy45.start(Unknown Source)
	at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:466)
	at sun.reflect.GeneratedMethodAccessor85.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
	at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
	at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:87)
	at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
	at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
	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 $Proxy46.start(Unknown Source)
	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
	at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.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(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
	at $Proxy0.start(Unknown Source)
	at org.jboss.system.ServiceController.start(ServiceController.java:417)
	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.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:304)
	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(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.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(Unknown Source)
Caused by: javax.naming.NameAlreadyBoundException
	at org.jnp.server.NamingServer.bind(NamingServer.java:144)
	at org.jnp.interfaces.NamingContext.bind(NamingContext.java:591)
	at org.jnp.interfaces.NamingContext.bind(NamingContext.java:552)
	at org.jboss.web.AbstractWebDeployer.parseWebAppDescriptors(AbstractWebDeployer.java:495)
	at org.jboss.web.AbstractWebDeployer$DescriptorParser.parseWebAppDescriptors(AbstractWebDeployer.java:878)
	at org.jboss.web.tomcat.service.TomcatDeployer.performDeployInternal(TomcatDeployer.java:159)
	at org.jboss.web.tomcat.service.TomcatDeployer.performDeploy(TomcatDeployer.java:104)
	at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:375)
	... 112 more
2009-07-10 12:28:31,718 ERROR [org.jboss.deployment.MainDeployer] Could not start deployment: file:/C:/jboss-4.2/server/default/tmp/deploy/tmp4660403835223254272ActixOne.ear-contents/TestWar.war
org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)
	at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:384)
	at org.jboss.web.WebModule.startModule(WebModule.java:83)
	at org.jboss.web.WebModule.startService(WebModule.java:61)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
	at $Proxy0.start(Unknown Source)
	at org.jboss.system.ServiceController.start(ServiceController.java:417)
	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.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 $Proxy45.start(Unknown Source)
	at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:466)
	at sun.reflect.GeneratedMethodAccessor85.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
	at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
	at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:87)
	at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
	at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
	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 $Proxy46.start(Unknown Source)
	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
	at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.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(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
	at $Proxy0.start(Unknown Source)
	at org.jboss.system.ServiceController.start(ServiceController.java:417)
	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.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:304)
	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(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.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(Unknown Source)
Caused by: javax.naming.NameAlreadyBoundException
	at org.jnp.server.NamingServer.bind(NamingServer.java:144)
	at org.jnp.interfaces.NamingContext.bind(NamingContext.java:591)
	at org.jnp.interfaces.NamingContext.bind(NamingContext.java:552)
	at org.jboss.web.AbstractWebDeployer.parseWebAppDescriptors(AbstractWebDeployer.java:495)
	at org.jboss.web.AbstractWebDeployer$DescriptorParser.parseWebAppDescriptors(AbstractWebDeployer.java:878)
	at org.jboss.web.tomcat.service.TomcatDeployer.performDeployInternal(TomcatDeployer.java:159)
	at org.jboss.web.tomcat.service.TomcatDeployer.performDeploy(TomcatDeployer.java:104)
	at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:375)
	... 112 more
2009-07-10 12:28:31,718 ERROR [org.jboss.deployment.scanner.URLDeploymentScanner] Incomplete Deployment listing:

--- Incompletely deployed packages ---
org.jboss.deployment.DeploymentInfo at 11dba24c { url=file:/C:/jboss-4.2/server/default/deploy/ActixOne.ear }
  deployer: org.jboss.deployment.EARDeployer at 7981d5
  status: Deployment FAILED reason: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)
  state: FAILED
  watch: file:/C:/jboss-4.2/server/default/deploy/ActixOne.ear
  altDD: null
  lastDeployed: 1247225246750
  lastModified: 1247225222906
  mbeans:
    jboss.j2ee:ear=ActixOne.ear,jar=Admin.jar,name=Admin,service=EJB3 state: Started
    persistence.units:ear=ActixOne.ear,jar=Settings.jar,unitName=SettingsStorage state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Settings.jar,name=Settings,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Layer3Msg.jar,name=Layer3Msg,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Layer3MsgMdb.jar,name=ReportProducerMDB,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Common.jar,name=Common,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Attributes.jar,name=Attributes,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Data.jar,name=Data,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Model.jar,name=Model,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Users.jar,name=Users,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Tasks.jar,name=Tasks,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Survey.jar,name=Survey,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=BenchmarkQpis.jar,name=Benchmarkqpis,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Cellrefutils.jar,name=Cellrefutils,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=ConfigChanges.jar,name=Configchanges,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Engine.jar,name=Engine,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Events.jar,name=Events,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=QueryDefs.jar,name=QueryDefs,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=QueryData.jar,name=QueryData,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=GeoTagging.jar,name=Geotagging,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Kpievents.jar,name=Kpievents,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Modules.jar,name=Modules,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Network.jar,name=Network,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=Qpis.jar,name=Qpis,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=RadioNetworkAnalysis.jar,name=RadioNetworkAnalysis,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=VirtualEarth.jar,name=VirtualEarth,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=WMS.jar,name=Wms,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=ReportData.jar,name=ReportData,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=ReportsMetadata.jar,name=ReportsMetadata,service=EJB3 state: Started
    jboss.j2ee:ear=ActixOne.ear,jar=ReportProducer.jar,name=ReportProducerMDB,service=EJB3 state: Started

--- MBeans waiting for other MBeans ---
ObjectName: jboss:service=KeyGeneratorFactory,type=HiLo
  State: CONFIGURED
  I Depend On:
    jboss:service=TransactionManager
    jboss.jca:service=DataSourceBinding,name=DefaultDS

ObjectName: jboss.cache:service=InvalidationBridge,type=JavaGroups
  State: CONFIGURED
  I Depend On:
    jboss:service=DefaultPartition
    jboss.cache:service=InvalidationManager

ObjectName: jboss.mq:service=InvocationLayer,type=HTTP
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=Invoker
    jboss.web:service=WebServer

ObjectName: jboss.mq:service=StateManager
  State: CONFIGURED
  I Depend On:
    jboss.jca:service=DataSourceBinding,name=DefaultDS
  Depends On Me:
    jboss.mq:service=DestinationManager

ObjectName: jboss.mq:service=DestinationManager
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=MessageCache
    jboss.mq:service=PersistenceManager
    jboss.mq:service=StateManager
    jboss.mq:service=ThreadPool
    jboss:service=Naming
  Depends On Me:
    jboss.mq.destination:service=Topic,name=testTopic
    jboss.mq.destination:service=Topic,name=securedTopic
    jboss.mq.destination:service=Topic,name=testDurableTopic
    jboss.mq.destination:service=Queue,name=testQueue
    jboss.mq.destination:service=Queue,name=A
    jboss.mq.destination:service=Queue,name=B
    jboss.mq.destination:service=Queue,name=C
    jboss.mq.destination:service=Queue,name=D
    jboss.mq.destination:service=Queue,name=ex
    jboss.mq:service=SecurityManager
    jboss.mq.destination:service=Queue,name=DLQ

ObjectName: jboss.mq:service=PersistenceManager
  State: CONFIGURED
  I Depend On:
    jboss.jca:service=DataSourceBinding,name=DefaultDS
  Depends On Me:
    jboss.mq:service=DestinationManager

ObjectName: jboss.mq.destination:service=Topic,name=testTopic
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager
    jboss.mq:service=SecurityManager

ObjectName: jboss.mq.destination:service=Topic,name=securedTopic
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager
    jboss.mq:service=SecurityManager

ObjectName: jboss.mq.destination:service=Topic,name=testDurableTopic
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager
    jboss.mq:service=SecurityManager

ObjectName: jboss.mq.destination:service=Queue,name=testQueue
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager
    jboss.mq:service=SecurityManager

ObjectName: jboss.mq.destination:service=Queue,name=A
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager

ObjectName: jboss.mq.destination:service=Queue,name=B
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager

ObjectName: jboss.mq.destination:service=Queue,name=C
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager

ObjectName: jboss.mq.destination:service=Queue,name=D
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager

ObjectName: jboss.mq.destination:service=Queue,name=ex
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager

ObjectName: jboss.mq:service=Invoker
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=TracingInterceptor
    jboss:service=Naming
  Depends On Me:
    jboss.mq:service=InvocationLayer,type=HTTP
    jboss.mq:service=InvocationLayer,type=JVM
    jboss.mq:service=InvocationLayer,type=UIL2

ObjectName: jboss.mq:service=TracingInterceptor
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=SecurityManager
  Depends On Me:
    jboss.mq:service=Invoker

ObjectName: jboss.mq:service=SecurityManager
  State: CONFIGURED
  I Depend On:
    jboss.security:service=JaasSecurityManager
    jboss.mq:service=DestinationManager
  Depends On Me:
    jboss.mq.destination:service=Topic,name=testTopic
    jboss.mq.destination:service=Topic,name=securedTopic
    jboss.mq.destination:service=Topic,name=testDurableTopic
    jboss.mq.destination:service=Queue,name=testQueue
    jboss.mq:service=TracingInterceptor
    jboss.mq.destination:service=Queue,name=DLQ

ObjectName: jboss.mq.destination:service=Queue,name=DLQ
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=DestinationManager
    jboss.mq:service=SecurityManager

ObjectName: jboss.mq:service=InvocationLayer,type=JVM
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=Invoker

ObjectName: jboss.mq:service=InvocationLayer,type=UIL2
  State: CONFIGURED
  I Depend On:
    jboss.mq:service=Invoker

ObjectName: jboss.web.deployment:war=TestWar.war,id=2043149425
  State: FAILED
  Reason: org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)

--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.web.deployment:war=TestWar.war,id=2043149425
  State: FAILED
  Reason: org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)

ObjectName: jboss.cache:service=InvalidationManager
  State: NOTYETINSTALLED
  Depends On Me:
    jboss.cache:service=InvalidationBridge,type=JavaGroups

ObjectName: jboss.jca:service=DataSourceBinding,name=DefaultDS
  State: NOTYETINSTALLED
  Depends On Me:
    jboss:service=KeyGeneratorFactory,type=HiLo
    jboss.mq:service=StateManager
    jboss.mq:service=PersistenceManager

*********************************************************************

I found out that I'm not the only one with problem like that:
http://www.techienuggets.com/Detail?tx=27457

Regards,
Michal Rorat

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 10:00:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Fri, 10 Jul 2009 10:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7088) expressions like
 'ne', 'eq' are not working in jboss
In-Reply-To: <170839805.1247141429138.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <861623540.1247234429357.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert resolved JBAS-7088.
--------------------------------

    Resolution: Rejected


This all works as expected.  Execute attachment in JSFUNIT-221.

> expressions like 'ne','eq' are not working in jboss
> ---------------------------------------------------
>
>                 Key: JBAS-7088
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7088
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: windows
>            Reporter: anil kumar
>            Assignee: Stan Silvert
>
> <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
>               <h:column rendered="#{screenConfig.displayTitle ne 'dashboard'}">
>               <h:outputText  value="#{screenConfig.displayTitle}"> </h:outputText>
>                </h:column>
>   </h:dataTable>
>  expressions like 'ne','eq' are not working in jboss but its working fine in Glassfish.
>  please suggest me on fixing this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 10:04:29 2009
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 10 Jul 2009 10:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6627) The JMX console
 /MBean Inspector page doesn't handle org.w3c.dom.Element correctly
In-Reply-To: <24936943.1237209442677.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1450414136.1247234669156.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned JBAS-6627:
--------------------------------------

    Assignee:     (was: Darran Lofthouse)


> The JMX console /MBean Inspector page doesn't handle org.w3c.dom.Element correctly
> ----------------------------------------------------------------------------------
>
>                 Key: JBAS-6627
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6627
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX/Web Console
>    Affects Versions: JBossAS-4.2.3.GA
>            Reporter: Howard Gao
>
> When a mbean is opened in the MBeanInspector page, if the mbean has attributes that are of type org.w3c.dom.Element, the corresponding input field cannot display them correctly if the element's value contains special characters like ' (quote). Special characters in this case should be converted to html code in order to be displayed properly on the web browser.
> See related jira https://jira.jboss.org/jira/browse/JBMESSAGING-1517.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 10:52:29 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Fri, 10 Jul 2009 10:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7094) JaasSecurityDomain
 fails to decrypt some PBE passwords
Message-ID: <1553321981.1247237549766.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JaasSecurityDomain fails to decrypt some PBE passwords
------------------------------------------------------

                 Key: JBAS-7094
                 URL: https://jira.jboss.org/jira/browse/JBAS-7094
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Marcus Moyses
            Assignee: Marcus Moyses
             Fix For: JBossAS-5.2.0.Beta1


Certain passwords when encrypted with PBE result in a String with leading zeros. These leading zeros are not printed with the String so decrypting the password fails because of invalid number of bytes. An exception is thrown:

javax.crypto.IllegalBlockSizeException: Input length (with padding) not multiple of 8 bytes

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 11:05:29 2009
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Fri, 10 Jul 2009 11:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7094) JaasSecurityDomain
 fails to decrypt some PBE passwords
In-Reply-To: <1553321981.1247237549766.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1523791264.1247238329396.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcus Moyses resolved JBAS-7094.
---------------------------------

    Resolution: Done


Fixed leading zeros problem.

> JaasSecurityDomain fails to decrypt some PBE passwords
> ------------------------------------------------------
>
>                 Key: JBAS-7094
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7094
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Marcus Moyses
>            Assignee: Marcus Moyses
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Certain passwords when encrypted with PBE result in a String with leading zeros. These leading zeros are not printed with the String so decrypting the password fails because of invalid number of bytes. An exception is thrown:
> javax.crypto.IllegalBlockSizeException: Input length (with padding) not multiple of 8 bytes

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 11:05:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 10 Jul 2009 11:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1034799337.1247238329577.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475766#action_12475766 ] 

Ian Springer commented on EJBTHREE-1852:
----------------------------------------

Starting up a recent build of EAP5 with the 'all' config, I get 49 of the "EJBTHREE-1852: InterceptorInfoRepository is deprecated" warnings logged to the console:

http://pastebin.com/f78c3bb4

I think this is excessive. Can we do one of the following?

1) Change the code to throttle how often the warning is printed.
2) Change the level of the log message to DEBUG.
3) Change the log4j config to log messages from that class only at ERROR level be default.



> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>            Assignee: Carlo de Wolf
>             Fix For: 1.1.8
>
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 11:05:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 10 Jul 2009 11:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <69859154.1247238329785.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer reopened EJBTHREE-1852:
------------------------------------



> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>            Assignee: Carlo de Wolf
>             Fix For: 1.1.8
>
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 11:17:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Fri, 10 Jul 2009 11:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-203) Fix the state
 usage when doing Deployers::checkComplete
Message-ID: <635438890.1247239049671.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Fix the state usage when doing Deployers::checkComplete
-------------------------------------------------------

                 Key: JBDEPLOY-203
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-203
             Project: JBoss Deployers
          Issue Type: Bug
          Components: maindeployer
    Affects Versions: JBDEPLOY-2.0.8.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For:  JBDEPLOY-2.2.x


Currently we're using the wrong state to determine if some component is missing some dependency.
Instead of DependencyItem::getWhenRequired we should use getDependentState.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 11:17:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 11:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <54633873.1247239049604.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475774#action_12475774 ] 

jaikiran pai commented on EJBTHREE-1852:
----------------------------------------

The EAP branch probably needs this  JBAS-7004. 

> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>            Assignee: Carlo de Wolf
>             Fix For: 1.1.8
>
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 11:49:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Fri, 10 Jul 2009 11:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-203) Fix the state
 usage when doing Deployers::checkComplete
In-Reply-To: <635438890.1247239049671.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <401788058.1247240969499.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBDEPLOY-203.
----------------------------------

    Resolution: Done


> Fix the state usage when doing Deployers::checkComplete
> -------------------------------------------------------
>
>                 Key: JBDEPLOY-203
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-203
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: maindeployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For:  JBDEPLOY-2.2.x
>
>
> Currently we're using the wrong state to determine if some component is missing some dependency.
> Instead of DependencyItem::getWhenRequired we should use getDependentState.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 12:09:29 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 10 Jul 2009 12:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-204)
 DeployersImpl.checkComplete()
 should report asynchronous deployments differently
Message-ID: <366247431.1247242169112.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

DeployersImpl.checkComplete() should report asynchronous deployments differently
--------------------------------------------------------------------------------

                 Key: JBDEPLOY-204
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-204
             Project: JBoss Deployers
          Issue Type: Feature Request
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For:  JBDEPLOY-2.2.x




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 12:11:29 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 10 Jul 2009 12:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBDEPLOY-204)
 DeployersImpl.checkComplete()
 should report asynchronous deployments in progress differently
In-Reply-To: <366247431.1247242169112.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1188016163.1247242289409.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed JBDEPLOY-204.
-------------------------------

    Resolution: Done


> DeployersImpl.checkComplete() should report asynchronous deployments in progress differently
> --------------------------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-204
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-204
>             Project: JBoss Deployers
>          Issue Type: Feature Request
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 12:11:29 2009
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 10 Jul 2009 12:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBDEPLOY-204)
 DeployersImpl.checkComplete()
 should report asynchronous deployments in progress differently
In-Reply-To: <366247431.1247242169112.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <238958568.1247242289344.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated JBDEPLOY-204:
--------------------------------

    Summary: DeployersImpl.checkComplete() should report asynchronous deployments in progress differently  (was: DeployersImpl.checkComplete() should report asynchronous deployments differently)


> DeployersImpl.checkComplete() should report asynchronous deployments in progress differently
> --------------------------------------------------------------------------------------------
>
>                 Key: JBDEPLOY-204
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-204
>             Project: JBoss Deployers
>          Issue Type: Feature Request
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For:  JBDEPLOY-2.2.x
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 12:25:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 10 Jul 2009 12:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2202) Generated types
 should be Serializable
In-Reply-To: <1963762277.1247174669126.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1346957251.1247243129187.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2202.
----------------------------------

    Resolution: Done


Fixed. Thanks for reporting.

> Generated types should be Serializable
> --------------------------------------
>
>                 Key: JBRULES-2202
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2202
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler, drools-core
>    Affects Versions: 5.0.0.FINAL, 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> Hello,
> Recently I've been working with Drools version 5.0.1 to set up an event processor.  While doing so I have come
> across difficulties with the accumulate function, in that it will always throw a ClassCastException
> when inserting events that are declared within my drl file.  To illustrate this I've set up an example which is
> shown below.  I've search Google and the mailing list for several hours, but the only way past this problem
> appears to be that I will have to declare a class externally and make sure it implements Serializable.  Does
> anyone has suggestions for another approach?  Secondly, I would have assumed that since Drools was
> compiling these internally declared classes, that Serializable would have been implemented automatically.  So
> is this a result of the generated class not implementing Serializable, or have I missed something in my rules
> file?  Thanks.
> The important part of my drl file is:
> declare TestEvent
>    @role( event )
>    @expires(10s)
>    id : String
> end
> #This rule works fine when 'Accumulate Count' is commented out, and is used to make
> #sure that the event inserting has worked.
> rule "Is It There"
>     when
>         TestEvent() from entry-point "test"
>     then
>         System.out.println("Found a TestEvent.");
> end
> #This rule throws a ClassCastException when a TestEvent is inserted.
> rule "Accumulate Count"
>     when
>         $n : Number() from accumulate($t : TestEvent() from entry-point "test",    count($t))
>     then
>         System.out.println("Found " + $n + " events.");
> end
> The unit test does this:
> FactType testEventType = session.getKnowledgeBase().getFactType("com.drools.test", "TestEvent");
> for(int i = 0; i < 10; i++){
>     Object testEvent = testEventType.newInstance();
>     testEventType.set(testEvent, "id", "id");
>     WorkingMemoryEntryPoint mainStream = session.getWorkingMemoryEntryPoint("test");
>     mainStream.insert(event);
>     session.fireAllRules();
> }
> The exception I receive is:
> org.drools.RuntimeDroolsException: java.lang.ClassCastException: com.drools.test.TestEvent cannot be cast to java.io.Serializable
>     at org.drools.rule.Accumulate.accumulate(Accumulate.java:172)
>     at org.drools.reteoo.AccumulateNode.modifyTuple(AccumulateNode.java:424)
>     at org.drools.reteoo.AccumulateNode.assertObject(AccumulateNode.java:284)
>     at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:42)
>     at org.drools.reteoo.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:326)
>     at org.drools.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:221)
>     at org.drools.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:394)
>     at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1486)
>     at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:158)
>     at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:122)
>     at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:80)
>     at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:28)
>     at com.drools.test.MyUnitTest.testEvents(EvaluationTest.java:66)
>     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.springframework.test.context.junit4.SpringTestMethod.invoke(SpringTestMethod.java:160)
>     at org.springframework.test.context.junit4.SpringMethodRoadie.runTestMethod(SpringMethodRoadie.java:233)
>     at org.springframework.test.context.junit4.SpringMethodRoadie$RunBeforesThenTestThenAfters.run(SpringMethodRoadie.java:333)
>     at org.springframework.test.context.junit4.SpringMethodRoadie.runWithRepetitions(SpringMethodRoadie.java:217)
>     at org.springframework.test.context.junit4.SpringMethodRoadie.runTest(SpringMethodRoadie.java:197)
>     at org.springframework.test.context.junit4.SpringMethodRoadie.run(SpringMethodRoadie.java:143)
>     at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.invokeTestMethod(SpringJUnit4ClassRunner.java:160)
>     at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
>     at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
>     at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
>     at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
>     at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
>     at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:97)
>     at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
>     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)
> Caused by: java.lang.ClassCastException: com.drools.test.TestEvent cannot be cast to java.io.Serializable
>     at org.drools.base.accumulators.JavaAccumulatorFunctionExecutor.accumulate(JavaAccumulatorFunctionExecutor.java:110)
>     at org.drools.rule.Accumulate.accumulate(Accumulate.java:164)
>     ... 36 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 12:45:29 2009
From: jira-events at lists.jboss.org (Konstantin Pupkov (JIRA))
Date: Fri, 10 Jul 2009 12:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1681) fetch based
 on messageId doesn't work
In-Reply-To: <122780486.1247072451434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1354090614.1247244329248.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475794#action_12475794 ] 

Konstantin Pupkov commented on JBMESSAGING-1681:
------------------------------------------------

Well,
I don't come up with jboss' forums+products+packages... structures. I just want to improve product itself. From my prospective you are one team. I think jboss need to improve internal communications to avoid situations like that. 
When I will have time I can rise that issue in other forum group, but I guess you can do that faster. Just reassign this issue to other team what ever it is.


Konstantin  

P.S. Thank you for quick respond and help!

> fetch based on messageId doesn't work
> -------------------------------------
>
>                 Key: JBMESSAGING-1681
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1681
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Linux, Ubuntu 9, JBoss 5.1.0.GA, My SQL 5, Java 6
>            Reporter: Konstantin Pupkov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: mdb-with-error.zip
>
>
> here is me code on client:
> String msgId="ID:JBM-511cfd0b-b4a8-4148-bd69-127a1fdeecfe";-->no worries that message has been just created and 100% exists in my DB
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JMSMessageID='"+msgId+"'");
> Message msg1= recv.receive();---->hungs on forever
> I tied
> QueueReceiver recv= ConnectionFactory.getInstance().getSession().createReceiver(queue, "JBMessageID='"+msgId+"'"); --> this is according to documentation. failed as well
> Please fix it and keep standard approach: JMSMessageID not JBMessageID.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 13:26:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 10 Jul 2009 13:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
In-Reply-To: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1342014959.1247246789811.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7051:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: EmbJopr1_3 ProfileService)


> ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7051
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ejb3-tutorial-mdb.jar
>
>
> This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:
> 1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.
> 2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:
> container=JBossMQ|JBossMessaging
> which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.
> Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:
> 15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
> ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
> rvice=Queue, parent=JBoss EAP 5 (default)]
> org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
>         at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
>         at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
> rceManager.java:235)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
> figurationUIBean.java:144)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.seam.util.Reflections.invoke(Reflections.java:22)
>         at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
>         at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
> tion(ResourceConfigurationUIBean_$$_javassist_12.java)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
>         at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
>         at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
>         at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
>         at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
>         at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
>         at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
>         at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
>         at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
>         at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
>         at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>         at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>         at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
>         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:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
> a:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
> :70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
> operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
> a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
> ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
> ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
>         ... 84 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 13:26:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 10 Jul 2009 13:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
In-Reply-To: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1319844970.1247246789520.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer reopened JBAS-7051:
--------------------------------



Looks like there are still some mapping issues for the managed properties. When I go the Configuration tab in the admin console for a JBossMQ queue, I get an error on the page and the following exception in the server log:

 13:19:35,767 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
ueue, key=queue/tutorial/defaultedexample, name=queue/tutorial/defaultedexample, parent=JBoss EAP 5 (default)]
org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [Queue Resource with id [-
37].
        at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
        at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
rceManager.java:235)
        at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
figurationUIBean.java:144)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.jboss.seam.util.Reflections.invoke(Reflections.java:22)
        at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
        at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
        at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
        at org.jboss.seam.core.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
        at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
        at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
        at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
        at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
        at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
tion(ResourceConfigurationUIBean_$$_javassist_12.java)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
        at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
        at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
        at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
        at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
        at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
        at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
        at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
        at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
        at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
        at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
        at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
        at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
        at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
        at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
        at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
        at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
        at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
        at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
        at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
        at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
        at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
        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:235)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
a:126)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
:70)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.RuntimeException: [Warning] java.lang.reflect.UndeclaredThrowableException:Failed to get property '
consumerCount' on component 'jboss.mq.destination:name=defaultedtutorial,service=Queue'. -> javax.management.AttributeNo
tFoundException:not found: ConsumerCount
        ... 84 more


> ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7051
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ejb3-tutorial-mdb.jar
>
>
> This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:
> 1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.
> 2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:
> container=JBossMQ|JBossMessaging
> which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.
> Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:
> 15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
> ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
> rvice=Queue, parent=JBoss EAP 5 (default)]
> org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
>         at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
>         at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
> rceManager.java:235)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
> figurationUIBean.java:144)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.seam.util.Reflections.invoke(Reflections.java:22)
>         at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
>         at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
> tion(ResourceConfigurationUIBean_$$_javassist_12.java)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
>         at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
>         at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
>         at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
>         at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
>         at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
>         at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
>         at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
>         at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
>         at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
>         at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>         at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>         at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
>         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:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
> a:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
> :70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
> operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
> a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
> ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
> ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
>         ... 84 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 13:30:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 10 Jul 2009 13:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7051) ManagedObjects are
 exposed for
 JBossMQ topics and queues - the MOs have the same component type as the MOs
 exposed for JBossMessaging destinations
In-Reply-To: <28133795.1245787496527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <780380837.1247247029670.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475803#action_12475803 ] 

Ian Springer commented on JBAS-7051:
------------------------------------

Similarly, when I go to the Metrics tab for a JBossMQ queue, only the Message Count metric is displayed. All of the other metrics fail to be retrieved, and the following exceptions are dumped to the server log:

13:25:56,641 ERROR [JmsDestinationComponent] Failed to collect metric for MeasurementScheduleRequest[scheduleId=1, name=
deliveringCount, interval=0, enabled=true, dataType=MEASUREMENT, rawNumericType=null]
java.lang.reflect.UndeclaredThrowableException: Failed to get property 'deliveringCount' on component 'jboss.mq.destinat
ion:name=defaultedtutorial,service=Queue'.
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:119)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:278)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.management.AttributeNotFoundException: not found: DeliveringCount
        at org.jboss.mx.server.AbstractMBeanInvoker.getAttribute(AbstractMBeanInvoker.java:335)
        at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:565)
        at org.jboss.system.microcontainer.ServiceControllerContext.get(ServiceControllerContext.java:179)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:80)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:83)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:53)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.get(BasicKernelBus.java:76)
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:90)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:278)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 19 more
13:25:56,876 ERROR [JmsDestinationComponent] Failed to collect metric for MeasurementScheduleRequest[scheduleId=1, name=
messageStatistics.depth, interval=0, enabled=true, dataType=MEASUREMENT, rawNumericType=null]
java.lang.reflect.UndeclaredThrowableException: Failed to get property 'messageStatistics' on component 'jboss.mq.destin
ation:name=defaultedtutorial,service=Queue'.
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:119)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.management.AttributeNotFoundException: not found: MessageStatistics
        at org.jboss.mx.server.AbstractMBeanInvoker.getAttribute(AbstractMBeanInvoker.java:335)
        at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:565)
        at org.jboss.system.microcontainer.ServiceControllerContext.get(ServiceControllerContext.java:179)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:80)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:83)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:53)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.get(BasicKernelBus.java:76)
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:90)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 19 more
13:25:57,048 ERROR [JmsDestinationComponent] Failed to collect metric for MeasurementScheduleRequest[scheduleId=1, name=
messageStatistics.count, interval=0, enabled=true, dataType=MEASUREMENT, rawNumericType=null]
java.lang.reflect.UndeclaredThrowableException: Failed to get property 'messageStatistics' on component 'jboss.mq.destin
ation:name=defaultedtutorial,service=Queue'.
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:119)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.management.AttributeNotFoundException: not found: MessageStatistics
        at org.jboss.mx.server.AbstractMBeanInvoker.getAttribute(AbstractMBeanInvoker.java:335)
        at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:565)
        at org.jboss.system.microcontainer.ServiceControllerContext.get(ServiceControllerContext.java:179)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:80)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:83)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:53)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.get(BasicKernelBus.java:76)
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:90)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 19 more
13:25:57,079 ERROR [JmsDestinationComponent] Failed to collect metric for MeasurementScheduleRequest[scheduleId=1, name=
consumerCount, interval=0, enabled=true, dataType=MEASUREMENT, rawNumericType=null]
java.lang.reflect.UndeclaredThrowableException: Failed to get property 'consumerCount' on component 'jboss.mq.destinatio
n:name=defaultedtutorial,service=Queue'.
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:119)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:278)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.management.AttributeNotFoundException: not found: ConsumerCount
        at org.jboss.mx.server.AbstractMBeanInvoker.getAttribute(AbstractMBeanInvoker.java:335)
        at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:565)
        at org.jboss.system.microcontainer.ServiceControllerContext.get(ServiceControllerContext.java:179)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:80)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:83)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:53)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.get(BasicKernelBus.java:76)
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:90)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:278)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 19 more
13:25:57,110 ERROR [JmsDestinationComponent] Failed to collect metric for MeasurementScheduleRequest[scheduleId=1, name=
messageStatistics.countDelta, interval=0, enabled=true, dataType=MEASUREMENT, rawNumericType=null]
java.lang.reflect.UndeclaredThrowableException: Failed to get property 'messageStatistics' on component 'jboss.mq.destin
ation:name=defaultedtutorial,service=Queue'.
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:119)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.management.AttributeNotFoundException: not found: MessageStatistics
        at org.jboss.mx.server.AbstractMBeanInvoker.getAttribute(AbstractMBeanInvoker.java:335)
        at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:565)
        at org.jboss.system.microcontainer.ServiceControllerContext.get(ServiceControllerContext.java:179)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:80)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:83)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:53)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.get(BasicKernelBus.java:76)
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:90)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 19 more
13:25:57,188 ERROR [JmsDestinationComponent] Failed to collect metric for MeasurementScheduleRequest[scheduleId=1, name=
scheduledMessageCount, interval=0, enabled=true, dataType=MEASUREMENT, rawNumericType=null]
java.lang.reflect.UndeclaredThrowableException: Failed to get property 'scheduledMessageCount' on component 'jboss.mq.de
stination:name=defaultedtutorial,service=Queue'.
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:119)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:278)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.management.AttributeNotFoundException: not found: ScheduledMessageCount
        at org.jboss.mx.server.AbstractMBeanInvoker.getAttribute(AbstractMBeanInvoker.java:335)
        at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:565)
        at org.jboss.system.microcontainer.ServiceControllerContext.get(ServiceControllerContext.java:179)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:80)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:83)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:53)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.get(BasicKernelBus.java:76)
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:90)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:278)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 19 more
13:25:57,266 ERROR [JmsDestinationComponent] Failed to collect metric for MeasurementScheduleRequest[scheduleId=1, name=
messageStatistics.timeLastUpdate, interval=0, enabled=true, dataType=MEASUREMENT, rawNumericType=null]
java.lang.reflect.UndeclaredThrowableException: Failed to get property 'messageStatistics' on component 'jboss.mq.destin
ation:name=defaultedtutorial,service=Queue'.
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:119)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.management.AttributeNotFoundException: not found: MessageStatistics
        at org.jboss.mx.server.AbstractMBeanInvoker.getAttribute(AbstractMBeanInvoker.java:335)
        at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:565)
        at org.jboss.system.microcontainer.ServiceControllerContext.get(ServiceControllerContext.java:179)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:80)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:83)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:53)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.get(BasicKernelBus.java:76)
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:90)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 19 more
13:25:57,329 ERROR [JmsDestinationComponent] Failed to collect metric for MeasurementScheduleRequest[scheduleId=1, name=
messageStatistics.depthDelta, interval=0, enabled=true, dataType=MEASUREMENT, rawNumericType=null]
java.lang.reflect.UndeclaredThrowableException: Failed to get property 'messageStatistics' on component 'jboss.mq.destin
ation:name=defaultedtutorial,service=Queue'.
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:119)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.management.AttributeNotFoundException: not found: MessageStatistics
        at org.jboss.mx.server.AbstractMBeanInvoker.getAttribute(AbstractMBeanInvoker.java:335)
        at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:565)
        at org.jboss.system.microcontainer.ServiceControllerContext.get(ServiceControllerContext.java:179)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:80)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus$1.dispatch(BasicKernelBus.java:83)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:53)
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.get(BasicKernelBus.java:76)
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatch
er.java:90)
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.j
ava:81)
        at sun.reflect.GeneratedMethodAccessor432.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java
:97)
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
        at org.jboss.remoting.Client.invoke(Client.java:1724)
        at org.jboss.remoting.Client.invoke(Client.java:629)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
        at org.jboss.aop.generatedproxies.AOPProxy$1.get(AOPProxy$1.java)
        at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)

        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getSimpleValue(ManagedComponentComponent.java:280)
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:231)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
        ... 19 more


> ManagedObjects are exposed for JBossMQ topics and queues - the MOs have the same component type as the MOs exposed for JBossMessaging destinations
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7051
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7051
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-ejb3-tutorial-mdb.jar
>
>
> This is an issue, because some of the managed properties are not of the same type. For example "serverPeer" is exposed as a composite rather than a simple, as it is for JBM destinations (see the stack trace below). I think the we need to do one of the following:
> 1) Expose JBossMQ destinations as MOs with different component types than JBossMessaging destinations. This way clients can distinguish between the two and the managed properties don't have to be exactly the same.
> 2) Continue to use the same component types for JBossMQ and JBossMessaging destinations, but fix the disparities between the managed properties. If we do this, we also need to expose a managed property that indicates which container the destination corresponds to, e.g.:
> container=JBossMQ|JBossMessaging
> which will allow the Jopr plugin to distinguish between the two and expose them as different types of Resources.
> Here's the CCE that is caused by the 'serverPeer' prop not being of the expected type (simple string) on JBossMQ destination MOs:
> 15:19:43,782 ERROR [PluginContainerResourceManager] Error retrieving configuration for resource: Resource[id=-37, type=Q
> ueue, key=jboss.mq.destination:name=defaultedtutorial,service=Queue, name=jboss.mq.destination:name=defaultedtutorial,se
> rvice=Queue, parent=JBoss EAP 5 (default)]
> org.rhq.core.clientapi.agent.PluginContainerException: Cannot load Resource configuration for [-37]
>         at org.rhq.core.pc.configuration.ConfigurationManager.loadResourceConfiguration(ConfigurationManager.java:174)
>         at org.jboss.on.embedded.manager.pc.PluginContainerResourceManager.getResourceConfiguration(PluginContainerResou
> rceManager.java:235)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean.resourceConfiguration(ResourceCon
> figurationUIBean.java:144)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.seam.util.Reflections.invoke(Reflections.java:22)
>         at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
>         at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:56)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
>         at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
>         at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
>         at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
>         at org.jboss.on.embedded.ui.configuration.resource.ResourceConfigurationUIBean_$$_javassist_12.resourceConfigura
> tion(ResourceConfigurationUIBean_$$_javassist_12.java)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
>         at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:274)
>         at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
>         at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
>         at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
>         at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
>         at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:174)
>         at org.jboss.seam.navigation.Pages.callAction(Pages.java:711)
>         at org.jboss.seam.navigation.Pages.preRender(Pages.java:349)
>         at org.jboss.seam.jsf.SeamPhaseListener.preRenderPage(SeamPhaseListener.java:562)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:473)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:146)
>         at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:116)
>         at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)
>         at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
>         at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
>         at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
>         at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
>         at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
>         at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
>         at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
>         at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>         at org.jboss.on.embedded.LazyStartupFilter.doFilter(LazyStartupFilter.java:87)
>         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:235)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
> a:126)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
> :70)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.RuntimeException: [Warning] java.lang.RuntimeException:Failed to convert managed property ManagedPr
> operty{serverPeer,serverPeer,metaType=ImmutableCompositeMetaType{javax.management.ObjectName items=[name=domain type=jav
> a.lang.String], [name=keyPropertyList type=java.util.Properties]}} to RHQ property of type SimpleProperty[serverPeer] (T
> ype: STRING). -> java.lang.ClassCastException:org.rhq.core.domain.configuration.definition.PropertyDefinitionSimple cann
> ot be cast to org.rhq.core.domain.configuration.definition.PropertyDefinitionMap
>         ... 84 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 14:51:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 10 Jul 2009 14:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-111) SJC: Temporary files
 must be deleted before deployment
Message-ID: <826257874.1247251889119.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC: Temporary files must be deleted before deployment
------------------------------------------------------

                 Key: JBJCA-111
                 URL: https://jira.jboss.org/jira/browse/JBJCA-111
             Project: JBoss JCA
          Issue Type: Bug
          Components: Deployer
    Affects Versions: 1.0.0.Alpha1
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Make sure that the temporary directory that resource adapters that are extracted to are cleaned up first.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 14:53:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 10 Jul 2009 14:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-111) SJC: Temporary
 files must be deleted before deployment
In-Reply-To: <826257874.1247251889119.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <67214045.1247252009122.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-111.
-----------------------------------

    Resolution: Done


> SJC: Temporary files must be deleted before deployment
> ------------------------------------------------------
>
>                 Key: JBJCA-111
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-111
>             Project: JBoss JCA
>          Issue Type: Bug
>          Components: Deployer
>    Affects Versions: 1.0.0.Alpha1
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Make sure that the temporary directory that resource adapters that are extracted to are cleaned up first.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 14:57:29 2009
From: jira-events at lists.jboss.org (Brad Hawthorne (JIRA))
Date: Fri, 10 Jul 2009 14:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1868) Calling remote
 interface on local bean results in remote invocation
Message-ID: <1481871457.1247252249106.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Calling remote interface on local bean results in remote invocation
-------------------------------------------------------------------

                 Key: EJBTHREE-1868
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1868
             Project: EJB 3.0
          Issue Type: Bug
          Components: ejb3
            Reporter: Brad Hawthorne


See forum thread for details

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 15:16:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 15:16:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1868) Calling remote
 interface on local bean results in remote invocation
In-Reply-To: <1481871457.1247252249106.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <484121670.1247253389461.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned EJBTHREE-1868:
--------------------------------------

    Assignee: jaikiran pai


> Calling remote interface on local bean results in remote invocation
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1868
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1868
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: ejb3
>            Reporter: Brad Hawthorne
>            Assignee: jaikiran pai
>
> See forum thread for details

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 15:18:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 15:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1868) Calling remote
 interface on local bean results in remote invocation
In-Reply-To: <1481871457.1247252249106.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <661472969.1247253509237.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1868:
-----------------------------------

    Component/s: proxy-impl
                     (was: ejb3)


> Calling remote interface on local bean results in remote invocation
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1868
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1868
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: proxy-impl
>            Reporter: Brad Hawthorne
>            Assignee: jaikiran pai
>
> See forum thread for details

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 15:20:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 10 Jul 2009 15:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1868) Calling remote
 interface on local bean results in remote invocation
In-Reply-To: <1481871457.1247252249106.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <784432258.1247253629342.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475818#action_12475818 ] 

jaikiran pai commented on EJBTHREE-1868:
----------------------------------------

Will take a look. But if you have a simple application to reproduce this, then please attach it here. That will make things easier to reproduce.


> Calling remote interface on local bean results in remote invocation
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1868
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1868
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: proxy-impl
>            Reporter: Brad Hawthorne
>            Assignee: jaikiran pai
>
> See forum thread for details

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 15:23:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 10 Jul 2009 15:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-1143) CLONE [JBREM-877] -
 New Socket
 Connection is being Created for Every Client Request to the Server
Message-ID: <1703765675.1247253809257.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLONE [JBREM-877] - New Socket Connection is being Created for Every Client Request to the Server
-------------------------------------------------------------------------------------------------

                 Key: JBREM-1143
                 URL: https://jira.jboss.org/jira/browse/JBREM-1143
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: transport
    Affects Versions: 2.2.2.SP2
         Environment: Linux  os , Pentium duo Processor with 3.6 Ghz clock Speed, 4GB Ram in this Postgresql Database also Running
            Reporter: Kumarselvan Somasundaram
            Assignee: Ron Sigal
            Priority: Critical
             Fix For:  2.4.0.Beta2 (Pinto)


whenever  EJB3 client requests the Server new socket is being created. at the client side the socket connection pool is not being used. Hope there is some issue with the socket connection after getting response from the server,becoz of which the server side the connection is being closed. this increases the CPU utilization,

The same code is running fine in jboss 4.0.4 with jboss remoting 1.4.0

new remoting 2.2.2 SP4 only handling 1/4 of the load with high CPU utilization. 



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 15:26:45 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 10 Jul 2009 15:26:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-1143) CLONE [JBREM-877] -
 New Socket
 Connection is being Created for Every Client Request to the Server
In-Reply-To: <1703765675.1247253809257.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1838276016.1247254005889.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBREM-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ron Sigal updated JBREM-1143:
-----------------------------

                   Environment:     (was: Linux  os , Pentium duo Processor with 3.6 Ghz clock Speed, 4GB Ram in this Postgresql Database also Running)
                 Fix Version/s: 2.2.3.SP1
                                    (was:  2.4.0.Beta2 (Pinto))
             Affects Version/s: 2.2.3
                                    (was: 2.2.2.SP2)
                   Description: 
JBREM-877 is being cloned to port the feature back to the 2.2 branch.  The original description:

whenever  EJB3 client requests the Server new socket is being created. at the client side the socket connection pool is not being used. Hope there is some issue with the socket connection after getting response from the server,becoz of which the server side the connection is being closed. this increases the CPU utilization,

The same code is running fine in jboss 4.0.4 with jboss remoting 1.4.0

new remoting 2.2.2 SP4 only handling 1/4 of the load with high CPU utilization. 



  was:
whenever  EJB3 client requests the Server new socket is being created. at the client side the socket connection pool is not being used. Hope there is some issue with the socket connection after getting response from the server,becoz of which the server side the connection is being closed. this increases the CPU utilization,

The same code is running fine in jboss 4.0.4 with jboss remoting 1.4.0

new remoting 2.2.2 SP4 only handling 1/4 of the load with high CPU utilization. 



                      Priority: Major  (was: Critical)


> CLONE [JBREM-877] - New Socket Connection is being Created for Every Client Request to the Server
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBREM-1143
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1143
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 2.2.3
>            Reporter: Kumarselvan Somasundaram
>            Assignee: Ron Sigal
>             Fix For: 2.2.3.SP1
>
>
> JBREM-877 is being cloned to port the feature back to the 2.2 branch.  The original description:
> whenever  EJB3 client requests the Server new socket is being created. at the client side the socket connection pool is not being used. Hope there is some issue with the socket connection after getting response from the server,becoz of which the server side the connection is being closed. this increases the CPU utilization,
> The same code is running fine in jboss 4.0.4 with jboss remoting 1.4.0
> new remoting 2.2.2 SP4 only handling 1/4 of the load with high CPU utilization. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 15:52:29 2009
From: jira-events at lists.jboss.org (Brad Hawthorne (JIRA))
Date: Fri, 10 Jul 2009 15:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1868) Calling remote
 interface on local bean results in remote invocation
In-Reply-To: <1481871457.1247252249106.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <429705188.1247255549146.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475821#action_12475821 ] 

Brad Hawthorne commented on EJBTHREE-1868:
------------------------------------------

Sorry, I don't have anything simple prepared, I'll come up with something if you have troubles. 

Consider this unit test case though. If we make isLocal() public to simplify the test:

assertTrue("Invocations on singleton interceptor should be local", IsLocalProxyFactoryInterceptor.singleton.isLocal());

This currently fails. From what I understand by reading the code, it uses the system time of when the class was initialized to determine if it was created in the same vm. The singleton gets a stamp value of zero and thus is never considered local.

> Calling remote interface on local bean results in remote invocation
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1868
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1868
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: proxy-impl
>            Reporter: Brad Hawthorne
>            Assignee: jaikiran pai
>
> See forum thread for details

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 16:17:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 10 Jul 2009 16:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-1139) Modify PortUtil to
 allow a
 configurable range for MIN_UNPRIVILEGED_PORT and MAX_LEGAL_PORT.
In-Reply-To: <215395097.1246517211483.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2069166661.1247257049361.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBREM-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ron Sigal updated JBREM-1139:
-----------------------------

        Fix Version/s: 2.5.2 (Flounder)
                       2.2.3.SP1
    Affects Version/s: 2.2.3
                       2.5.1 (Flounder)
                           (was: 2.2.2.SP8)
             Assignee: Ron Sigal


> Modify PortUtil to allow a configurable range for MIN_UNPRIVILEGED_PORT and MAX_LEGAL_PORT.
> -------------------------------------------------------------------------------------------
>
>                 Key: JBREM-1139
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1139
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.5.1 (Flounder), 2.2.3
>            Reporter: Colin Mondesir
>            Assignee: Ron Sigal
>             Fix For: 2.5.2 (Flounder), 2.2.3.SP1
>
>
> PortUtil could be improved to read the port range configuration.
> This is straightforward and no side effect is expected.  However,
> PortUtil and its callers will need some refactoring as it is just a
> static utility classes currently.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 17:05:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 10 Jul 2009 17:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-1144) Extend connection
 identity to server side
Message-ID: <480005843.1247259929160.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Extend connection identity to server side
-----------------------------------------

                 Key: JBREM-1144
                 URL: https://jira.jboss.org/jira/browse/JBREM-1144
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.3, 2.5.1 (Flounder)
            Reporter: Ron Sigal
            Assignee: Ron Sigal
             Fix For: 2.5.2 (Flounder), 2.2.3.SP1


In JBREM-1128 "Introduce connection identity concept" and JBREM-1132 "CLONE [JBREM-1128] - Introduce connection identity concept", the server was equipped to recognized when a client had been replaced by another client.  In other words, clients were assigned an identity.  This concept should be extended to the server side, so that ConnectionValidator can detect that a server has been replaced.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 18:35:40 2009
From: jira-events at lists.jboss.org (Tom Murphy (JIRA))
Date: Fri, 10 Jul 2009 18:35:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2204) Exception not
 rethrown by AbstractWorkingMemory.executeQueuedActions()
Message-ID: <1550042503.1247265340995.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Exception not rethrown by AbstractWorkingMemory.executeQueuedActions() 
-----------------------------------------------------------------------

                 Key: JBRULES-2204
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2204
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
         Environment: JBoss AS 5.0, Windows Server 2003 SP2, Drools 5.0.1.FINAL
            Reporter: Tom Murphy
            Assignee: Mark Proctor


AbstractWorkingMemory.executeQueuedActions()  catches exceptions thrown within calls to action.execute() (line 1486). 

It then tests to see if the exception is a RuntimeDroolsException and rethrows it if it is. However, if it is not, it simply does a printStackTrace() on the exception and does not re-throw it. This is a problem because SplitInstance throws an IllegalArgumentException on line 73. This is then caught and gobbled by the catch clause starting on line 1487 of AbstractWorkingMemory.java. 

The result is that any service or application hosting the Drools runtime will never see this exception. What looks to the user like a clean (albeit overly shortened) rules session has in fact thrown an error, but it is not visible to the user or the owning service. It is therefore very difficult to diagnose why the rules and/or flows are not doing what they should.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 21:44:29 2009
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 10 Jul 2009 21:44:29 -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: <868747971.1247276669270.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/GPD-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475867#action_12475867 ] 

Ronald van Kuijk commented on GPD-35:
-------------------------------------

I know the GPD is GEF, not GMF but http://publib.boulder.ibm.com/infocenter/rsmhelp/v7r0m0/index.jsp?topic=/org.eclipse.gmf.doc/tutorials/diagram/createConnection.html is what is 'needed' for a much better user experience. Maybe time for a change ;-)

> enhancement drawing transitions
> -------------------------------
>
>                 Key: GPD-35
>                 URL: https://jira.jboss.org/jira/browse/GPD-35
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>            Reporter: 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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 10 21:46:29 2009
From: jira-events at lists.jboss.org (Ronald van Kuijk (JIRA))
Date: Fri, 10 Jul 2009 21:46:29 -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: <128925883.1247276789148.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/GPD-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475868#action_12475868 ] 

Ronald van Kuijk commented on GPD-35:
-------------------------------------

http://dev.eclipse.org/newslists/news.eclipse.modeling.gmf/msg17947.html

> enhancement drawing transitions
> -------------------------------
>
>                 Key: GPD-35
>                 URL: https://jira.jboss.org/jira/browse/GPD-35
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>            Reporter: 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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 11 09:19:29 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 11 Jul 2009 09:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14072601.1247318369510.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated JBAS-6185:
-------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1


> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Scott Marlow
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 11 09:19:29 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 11 Jul 2009 09:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <349737701.1247318369838.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved JBAS-6185.
--------------------------------

    Resolution: Done


added MBeanServerBuilderImpl + LazyMBeanServer to run.jar 

> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Scott Marlow
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 11 10:39:29 2009
From: jira-events at lists.jboss.org (Alejandro Guizar (JIRA))
Date: Sat, 11 Jul 2009 10:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-306) Variable Instances
 translation
 funcionality(From MessageValue to simple types like String,Integer,Long)
In-Reply-To: <2123265903.1246520763456.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <454961406.1247323169217.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/BPEL-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475883#action_12475883 ] 

Alejandro Guizar commented on BPEL-306:
---------------------------------------

Message variables are maps by definition. MessageValue is just a specialized map. It cannot be translated directly to a simple type because it may contain multiple values.

Other kinds of variables, those defined with simple or complex schema types, or elements, are represented as DOM elements. Of these, only simple types could be represented as plain strings. There is a good reason why they are not: being able to treat simple or complex schema types indistinctly. Anyhow, is getting strings from simple types what you are looking for?

> Variable Instances translation funcionality(From MessageValue to simple types like String,Integer,Long)
> -------------------------------------------------------------------------------------------------------
>
>                 Key: BPEL-306
>                 URL: https://jira.jboss.org/jira/browse/BPEL-306
>             Project: JBoss jBPM BPEL
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1.1
>         Environment: Jboss 4.2.3.GA
> JBPM-BPEL 1.1.1
>            Reporter: francesco dicarlo
>            Assignee: Alejandro Guizar
>
> Would be good to have a functionality (i.e. a Translator) to automatically translate VariableInstance that in JBPM-BPEL are of type MessageValue into the simple type that were defined in the workflow.
> The use of this code \\Map varsMap=instance.getContextInstance().getVariables();\\ returns a Map with key the name of the variable but with value a type MessageValue that can't be translated automatically for all the workflow because relies on workflow implementation and design.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 11 12:47:40 2009
From: jira-events at lists.jboss.org (Gurkan Erdogdu (JIRA))
Date: Sat, 11 Jul 2009 12:47:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-112) Adding Partial
 Implementation for Specification Chapter11
Message-ID: <546837010.1247330860697.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Adding Partial Implementation for Specification Chapter11
---------------------------------------------------------

                 Key: JBJCA-112
                 URL: https://jira.jboss.org/jira/browse/JBJCA-112
             Project: JBoss JCA
          Issue Type: Patch
          Components: Core
            Reporter: Gurkan Erdogdu
            Assignee: Jesper Pedersen
         Attachments: CommonProject.diff, CoreProject.diff, CoreTest.diff

I have implemented some of checks that are defined in the specification Chapter 11.

3 different patches exist

1* CommonProject.diff --> Contains utility class.

2* CoreProject.diff --> Updating WorkWrapper and WorkManagerImpl to support WorkContextProvider

3* CoreTest.diff --> Updating tests for Chapter 11


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 11 12:47:40 2009
From: jira-events at lists.jboss.org (Gurkan Erdogdu (JIRA))
Date: Sat, 11 Jul 2009 12:47:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-112) Adding Partial
 Implementation for Specification Chapter11
In-Reply-To: <546837010.1247330860697.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <106220501.1247330860783.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gurkan Erdogdu updated JBJCA-112:
---------------------------------

    Attachment: CommonProject.diff


> Adding Partial Implementation for Specification Chapter11
> ---------------------------------------------------------
>
>                 Key: JBJCA-112
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-112
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Core
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>         Attachments: CommonProject.diff, CoreProject.diff, CoreTest.diff
>
>
> I have implemented some of checks that are defined in the specification Chapter 11.
> 3 different patches exist
> 1* CommonProject.diff --> Contains utility class.
> 2* CoreProject.diff --> Updating WorkWrapper and WorkManagerImpl to support WorkContextProvider
> 3* CoreTest.diff --> Updating tests for Chapter 11

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 11 12:47:40 2009
From: jira-events at lists.jboss.org (Gurkan Erdogdu (JIRA))
Date: Sat, 11 Jul 2009 12:47:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-112) Adding Partial
 Implementation for Specification Chapter11
In-Reply-To: <546837010.1247330860697.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1328590447.1247330860926.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gurkan Erdogdu updated JBJCA-112:
---------------------------------

    Attachment: CoreProject.diff


> Adding Partial Implementation for Specification Chapter11
> ---------------------------------------------------------
>
>                 Key: JBJCA-112
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-112
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Core
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>         Attachments: CommonProject.diff, CoreProject.diff, CoreTest.diff
>
>
> I have implemented some of checks that are defined in the specification Chapter 11.
> 3 different patches exist
> 1* CommonProject.diff --> Contains utility class.
> 2* CoreProject.diff --> Updating WorkWrapper and WorkManagerImpl to support WorkContextProvider
> 3* CoreTest.diff --> Updating tests for Chapter 11

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 11 12:47:41 2009
From: jira-events at lists.jboss.org (Gurkan Erdogdu (JIRA))
Date: Sat, 11 Jul 2009 12:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-112) Adding Partial
 Implementation for Specification Chapter11
In-Reply-To: <546837010.1247330860697.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1010085915.1247330861062.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gurkan Erdogdu updated JBJCA-112:
---------------------------------

    Attachment: CoreTest.diff


> Adding Partial Implementation for Specification Chapter11
> ---------------------------------------------------------
>
>                 Key: JBJCA-112
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-112
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Core
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>         Attachments: CommonProject.diff, CoreProject.diff, CoreTest.diff
>
>
> I have implemented some of checks that are defined in the specification Chapter 11.
> 3 different patches exist
> 1* CommonProject.diff --> Contains utility class.
> 2* CoreProject.diff --> Updating WorkWrapper and WorkManagerImpl to support WorkContextProvider
> 3* CoreTest.diff --> Updating tests for Chapter 11

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 11 16:21:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Sat, 11 Jul 2009 16:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7089) <h:column> level
 rendering is not working in JBOSS
In-Reply-To: <1328936593.1247148869241.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1476111412.1247343689206.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert resolved JBAS-7089.
--------------------------------

    Resolution: Rejected


> <h:column> level rendering is not working in JBOSS 
> ---------------------------------------------------
>
>                 Key: JBAS-7089
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7089
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: windows
>            Reporter: anil kumar
>            Assignee: Stan Silvert
>
> <h:column> level rendering is not working in JBOSS but works in Glassfish.
>    <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
>              <h:column>
>              <h:outputText  value="#{screenConfig.displayTitle}"  rendered="#{'5' eq '5'}"> </h:outputText>   
>               </h:column>  
>          </h:dataTable> 
> this is working perfectly.
> <h:dataTable value="#{HeaderBean.records}" var="screenConfig">
>              <h:column  rendered="#{'5' eq '5'}"> >
>              <h:outputText  value="#{screenConfig.displayTitle}" </h:outputText>   
>               </h:column>  
>          </h:dataTable> 
> where as above one is not working. I really don't understand why this is not working in JBOSS.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 11 17:27:29 2009
From: jira-events at lists.jboss.org (Jaroslaw Kijanowski (JIRA))
Date: Sat, 11 Jul 2009 17:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2205) smooks core not
 shipped with the bin distribution
Message-ID: <152122708.1247347649157.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

smooks core not shipped with the bin distribution
-------------------------------------------------

                 Key: JBRULES-2205
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2205
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.1.FINAL
            Reporter: Jaroslaw Kijanowski
            Assignee: Mark Proctor


milyn-smooks-javabean-1.1.jar is shipped, but milyn-smooks-core-1.1.2.jar is missing in the zip distribution.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jul 12 23:36:29 2009
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 12 Jul 2009 23:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2130) DSL Bug while
 creating comparison combinations
In-Reply-To: <17065276.1245415796493.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1262856931.1247456189665.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Proctor updated JBRULES-2130:
----------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)
    Priority: Major  (was: Blocker)


> DSL Bug while creating comparison combinations
> ----------------------------------------------
>
>                 Key: JBRULES-2130
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2130
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>         Environment: I tried building the DSL using Guvnor
>            Reporter: Prem Stephen
>            Assignee: Edson Tirelli
>
> In http://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/docs/drools-expert/html_single/index.html#d0e5595, section 4.10.4 - I am expanding on the following syntax example for structuring combinations in the DSL.
> In my example, I have
> [when]There is a Contact with=Contact()
> [when]- age is less than {age}=age < {age}
> [when]- age is greater than {age}=age > {age}
> [when]- age is less than or equal to {age}=age <= {age}   <-------------------- this line does not work
> [when]- age is foo than or equal to {age}=age <= {age}
> and my rule is
> when
> 	There is a Contact with
> 	- age is foo than or equal to 35
> 	
> then
> 	Log : "Contact exists Test";
> Now, the line that does not work is because it shares the start "age is less than " with an earlier DSL.
> Replacing "less" with "foo" works for this reason.
> I think the parsing needs to be fixed to look at the whole sentence.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 04:07:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 13 Jul 2009 04:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-113) Support standard 303
 validation annotation
Message-ID: <713920493.1247472449189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Support standard 303 validation annotation
------------------------------------------

                 Key: JBJCA-113
                 URL: https://jira.jboss.org/jira/browse/JBJCA-113
             Project: JBoss JCA
          Issue Type: Task
          Components: Deployer
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha2


*) ra16standard303.rar (Valid (@NotNull) - must be deployed)

Create a resource adapter in deployer/test that uses standard 303 defined 
tags like @NotNull and @Min

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 04:09:40 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 13 Jul 2009 04:09:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-114) Support customer 303
 validation annotation
Message-ID: <940958141.1247472580910.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Support customer 303 validation annotation
------------------------------------------

                 Key: JBJCA-114
                 URL: https://jira.jboss.org/jira/browse/JBJCA-114
             Project: JBoss JCA
          Issue Type: Task
          Components: Deployer
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha2


*) ra16user303.rar (Valid (@FrenchZipcode) - must be deployed)

Create a resource adapter in deployer/test that uses custom defined tags - 
an example would be @FrenchZipcode from the 303 spec. The resource adapter 
must of course include the classes needed to make this happen

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 04:13:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 13 Jul 2009 04:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-116) Negative test for
 customer 303 validation annotation
Message-ID: <673733390.1247472809337.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Negative test for customer 303 validation annotation
----------------------------------------------------

                 Key: JBJCA-116
                 URL: https://jira.jboss.org/jira/browse/JBJCA-116
             Project: JBoss JCA
          Issue Type: Task
          Components: Deployer
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha2


ra16user303jbossra.rar (Invalid - must fail)

define in ra.xml and override in jboss-ra.xml, validate should be fail

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 04:13:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 13 Jul 2009 04:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-115) Negative test for
 standard 303 validation annotation
Message-ID: <1562454476.1247472809212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Negative test for standard 303 validation annotation
----------------------------------------------------

                 Key: JBJCA-115
                 URL: https://jira.jboss.org/jira/browse/JBJCA-115
             Project: JBoss JCA
          Issue Type: Task
          Components: Deployer
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha3


ra16standard303jbossra.rar (Invalid - must fail)

define in ra.xml and override in jboss-ra.xml, validate should be fail

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 07:12:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 13 Jul 2009 07:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1682) duplicate key
 value
 violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1749881008.1247483549295.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1682.
-----------------------------------

    Resolution: Done


Done.

format now: (starting from highest bit)

First 10 bits - node id
Next 39 bits - 4th - 42nd bits of system time
Next 15 bits - rotating counter


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 07:12:29 2009
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Mon, 13 Jul 2009 07:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2206) exists Foo() does
 not fire if facts inserted before rule
Message-ID: <1053908145.1247483549402.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

exists Foo() does not fire if facts inserted before rule
--------------------------------------------------------

                 Key: JBRULES-2206
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2206
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core  (expert)
    Affects Versions: 5.0.1.FINAL
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor


Facts of some type Foo are inserted into a StatefulKnowledgeSession, then a rule with LHS exists Foo() is added and fireAllRules() is called, but the rule does not fire.

If the same is done with the FOP-equivalent rule containing CE not(not Foo()), the rule fires.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 07:21:29 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 13 Jul 2009 07:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-214)
 SchemaBindingValidator: complex
 types with adapters should pass validation as simple types
Message-ID: <1988836401.1247484089266.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SchemaBindingValidator: complex types with adapters should pass validation as simple types
------------------------------------------------------------------------------------------

                 Key: JBXB-214
                 URL: https://jira.jboss.org/jira/browse/JBXB-214
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.2.Beta1
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: JBossXB-2.0.2.GA


At the moment the fact that the complex type has an adapter associated with it is ignored during validation. And comparison of such complex types to XSD simple types fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 07:21:29 2009
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Mon, 13 Jul 2009 07:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2206) exists Foo() does
 not fire if facts inserted before rule
In-Reply-To: <1053908145.1247483549402.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <672837023.1247484089204.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolfgang Laun updated JBRULES-2206:
-----------------------------------

    Attachment: RuleTester.java
                test1.drl
                test2.drl


> exists Foo() does not fire if facts inserted before rule
> --------------------------------------------------------
>
>                 Key: JBRULES-2206
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2206
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Wolfgang Laun
>            Assignee: Mark Proctor
>         Attachments: RuleTester.java, test1.drl, test2.drl
>
>
> Facts of some type Foo are inserted into a StatefulKnowledgeSession, then a rule with LHS exists Foo() is added and fireAllRules() is called, but the rule does not fire.
> If the same is done with the FOP-equivalent rule containing CE not(not Foo()), the rule fires.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 07:25:29 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 13 Jul 2009 07:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-214)
 SchemaBindingValidator: complex
 types with adapters should pass validation as simple types
In-Reply-To: <1988836401.1247484089266.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <65852508.1247484329333.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBXB-214.
----------------------------------

    Resolution: Done


Done.

> SchemaBindingValidator: complex types with adapters should pass validation as simple types
> ------------------------------------------------------------------------------------------
>
>                 Key: JBXB-214
>                 URL: https://jira.jboss.org/jira/browse/JBXB-214
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.2.Beta1
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossXB-2.0.2.GA
>
>
> At the moment the fact that the complex type has an adapter associated with it is ignored during validation. And comparison of such complex types to XSD simple types fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 07:27:43 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 13 Jul 2009 07:27:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1867) Track the
 upgrades during EJB3 plugin 1.0.11 release
In-Reply-To: <260824002.1247218949130.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1516304148.1247484463941.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1867.
------------------------------------

                  Resolution: Done
    Component Fix Version(s): jboss-ejb3-plugin:1.0.11


> Track the upgrades during EJB3 plugin 1.0.11 release
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1867
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1867
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: plugin
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> This JIRA will track the dependency upgrades during the release of EJB3 plugin 1.0.11

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 07:37:29 2009
From: jira-events at lists.jboss.org (Naresh Bhatia (JIRA))
Date: Mon, 13 Jul 2009 07:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <612775691.1247485049349.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Naresh Bhatia reopened JBMESSAGING-1677:
----------------------------------------



Corrected original issue with 1000 messages by connecting correctly to JCA connection factory. No the problem occurs when we hit 3000 messages on a Windows machine.

> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Clebert Suconic
>         Attachments: JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 07:37:29 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 13 Jul 2009 07:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-215) add JBossXml
 annotation to filter
 transient properties in classes on a package level
Message-ID: <241823731.1247485049245.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

add JBossXml annotation to filter transient properties in classes on a package level
------------------------------------------------------------------------------------

                 Key: JBXB-215
                 URL: https://jira.jboss.org/jira/browse/JBXB-215
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Feature Request
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: JBossXB-2.0.2.GA


The prototype has been committed and currently looks like this (excerpt from package-info.java)

@JBossXmlTransients({
   // mark specific property in the type as transient
   @JBossXmlTransient(type = JBossObject.class, properties={"classShortName"}),
   // not specifying properties will make them all transient in the type
   @JBossXmlTransient(type = Base.class)
})
package org.jboss.test.xb.builder.object.jbossxmltransient.support;

import org.jboss.util.JBossObject;
import org.jboss.xb.annotations.JBossXmlTransient;import org.jboss.xb.annotations.JBossXmlTransients;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 07:39:29 2009
From: jira-events at lists.jboss.org (Naresh Bhatia (JIRA))
Date: Mon, 13 Jul 2009 07:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1309874794.1247485169254.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Naresh Bhatia updated JBMESSAGING-1677:
---------------------------------------

    Attachment: JmsTest-v2.zip


Attaching v2 of the code that demonstrates the issue with 3000 messages on a windows machine.

> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Clebert Suconic
>         Attachments: JmsTest-v2.zip, JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 07:46:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 13 Jul 2009 07:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1869) Upgrade
 jboss-ejb3-build dependency in testsuite to 1.0.5-SNAPSHOT
Message-ID: <1684396779.1247485589262.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade jboss-ejb3-build dependency in testsuite to 1.0.5-SNAPSHOT
------------------------------------------------------------------

                 Key: EJBTHREE-1869
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1869
             Project: EJB 3.0
          Issue Type: Task
          Components: testsuite
            Reporter: jaikiran pai
            Assignee: jaikiran pai


The jobs on slaves of mike are failing to resolve the 1.0.4-SNAPSHOT or 1.0.4 of jboss-ejb3-build for 2 reasons:

1) The 1.0.4-SNAPSHOT of jboss-ejb3-build is not available through the relative path
2) The Maven settings on slaves are not pointing to jboss repo.

As a workaround, upgrade the jboss-ejb3-build dependency in testsuite to 1.0.5-SNAPSHOT (so that it is resolved locally through relative path).


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 08:12:29 2009
From: jira-events at lists.jboss.org (Changalasetti Nagakiran (JIRA))
Date: Mon, 13 Jul 2009 08:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6442) Response truncated
 in the presence of special character
In-Reply-To: <31820059.1233348224581.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <55128503.1247487149359.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476002#action_12476002 ] 

Changalasetti Nagakiran commented on JBAS-6442:
-----------------------------------------------

Hi, we have similear kind of issues happening with our application. 
Currently our application is running on Oracle 10G server and planning to migrate to Jboss. In our JBOSS development envornment many pages were truncated bacause of special characters. 

when can we expect fix for this issue. or could you please provide us some alternative solution. 
Thanks.
-NK

> Response truncated in the presence of special character
> -------------------------------------------------------
>
>                 Key: JBAS-6442
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6442
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows XP, JDK 1.6.0_11
>            Reporter: Juan Manuel Medina Apodaca
>            Assignee: Remy Maucherat
>         Attachments: SpecialCharacter.txt
>
>
> When a servlet puts a session attribute containing a collection of strings, one of the strings contains a special character (for example: ...) and this string is displayed in a JSP, the resulting page is truncated before the special character.
> For example, in a servlet:
> ArrayList optionList = new ArrayList();
> ...
> optionList.add("Any string 1");
> optionList.add("Any string 2");
> optionList.add("Any string 3");
> optionList.add("Any string 4");
> optionList.add("A string with ... character");
> optionList.add("Any string 6");
> optionList.add("Any string 7");
> optionList.add("Any string 8");
> ...
> request.getSession(false).setAttribute("myList", optionList);
> In the JSP:
> 			               <c:forEach var="currentOption" items="${myList}">
> 			                  ${currentOption}
> 			                </c:forEach>
> The resulting page gets truncated before the 5th line.
> In JBoss 4.0.0 the page shows complete, with a ? sign in the place of the special character.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 09:06:42 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 13 Jul 2009 09:06:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-116) Negative test for
 custom 303 validation annotation
In-Reply-To: <673733390.1247472809337.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <71199135.1247490402166.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang updated JBJCA-116:
-----------------------------

    Summary: Negative test for custom 303 validation annotation  (was: Negative test for customer 303 validation annotation)


> Negative test for custom 303 validation annotation
> --------------------------------------------------
>
>                 Key: JBJCA-116
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-116
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> ra16user303jbossra.rar (Invalid - must fail)
> define in ra.xml and override in jboss-ra.xml, validate should be fail

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 09:06:42 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 13 Jul 2009 09:06:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-114) Support custom 303
 validation annotation
In-Reply-To: <940958141.1247472580910.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1217838932.1247490402065.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang updated JBJCA-114:
-----------------------------

    Summary: Support custom 303 validation annotation  (was: Support customer 303 validation annotation)


> Support custom 303 validation annotation
> ----------------------------------------
>
>                 Key: JBJCA-114
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-114
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> *) ra16user303.rar (Valid (@FrenchZipcode) - must be deployed)
> Create a resource adapter in deployer/test that uses custom defined tags - 
> an example would be @FrenchZipcode from the 303 spec. The resource adapter 
> must of course include the classes needed to make this happen

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 09:39:41 2009
From: jira-events at lists.jboss.org (Alfie Kirkpatrick (JIRA))
Date: Mon, 13 Jul 2009 09:39:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-356) Designer creates
 duplicate handler nodes under decision nodes
Message-ID: <2099402771.1247492381837.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Designer creates duplicate handler nodes under decision nodes
-------------------------------------------------------------

                 Key: GPD-356
                 URL: https://jira.jboss.org/jira/browse/GPD-356
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM jPDL Designer 4.0.0.GA
            Reporter: Alfie Kirkpatrick
            Assignee: Koen Aers
            Priority: Minor


When switching between text mode and graphical mode and saving the process definition a few times a large number of handler elements can build up under each decision node. This doesn't seem to affect the running of the process so is more an inconvenience than anything, but could cause confusion if the handler parameters are modified.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 09:41:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Mon, 13 Jul 2009 09:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7052) when invoked from
 remote client, 
 call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1346784883.1247492489680.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7052:
---------------------------------

    Assignee: Ian Springer  (was: Scott M Stark)


> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Ian Springer
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 09:41:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Mon, 13 Jul 2009 09:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7052) when invoked from
 remote
 client, call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1978474975.1247492489909.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476025#action_12476025 ] 

Charles Crouch commented on JBAS-7052:
--------------------------------------

Ian, can you retest this please.

> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Ian Springer
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 09:52:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Mon, 13 Jul 2009 09:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-205) Provide a way to
 handle exceptions while doing check complete
Message-ID: <1231079725.1247493149630.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Provide a way to handle exceptions while doing check complete
-------------------------------------------------------------

                 Key: JBDEPLOY-205
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-205
             Project: JBoss Deployers
          Issue Type: Feature Request
          Components: maindeployer
    Affects Versions: JBDEPLOY-2.0.8.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For:  JBDEPLOY-2.2.x


Allow for exception handling in Deployers::checkComplete.
Introducing new ExceptionHandler interface.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 09:54:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 09:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-226) Define a repeatable
 build for these plugins to be exported as a feature
In-Reply-To: <23044378.1216376452176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1325572540.1247493269168.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers closed GPD-226.
-------------------------

    Resolution: Done


> Define a repeatable build for these plugins to be exported as a feature
> -----------------------------------------------------------------------
>
>                 Key: GPD-226
>                 URL: https://jira.jboss.org/jira/browse/GPD-226
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 09:56:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 09:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-351) Modify project and
 jpdl creation wizards to allow for jBPM 3 and jBPM 4 to coexist
In-Reply-To: <20923654.1243721096388.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <348484753.1247493389145.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-351.
---------------------------

    Resolution: Done


> Modify project and jpdl creation wizards to allow for jBPM 3 and jBPM 4 to coexist
> ----------------------------------------------------------------------------------
>
>                 Key: GPD-351
>                 URL: https://jira.jboss.org/jira/browse/GPD-351
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 09:56:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 09:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-333) Ensure backwards
 compatibility between GPD 3.1.x and GPD 4.x
In-Reply-To: <25062383.1241703286559.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <266840403.1247493389223.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-333.
---------------------------

    Resolution: Done


> Ensure backwards compatibility between GPD 3.1.x and GPD 4.x
> ------------------------------------------------------------
>
>                 Key: GPD-333
>                 URL: https://jira.jboss.org/jira/browse/GPD-333
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 09:58:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 09:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-307) make g the last
	attribute
In-Reply-To: <13029711.1238663482840.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1429182412.1247493509155.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-307:
--------------------------

    Component/s: jpdl


> make g the last attribute
> -------------------------
>
>                 Key: GPD-307
>                 URL: https://jira.jboss.org/jira/browse/GPD-307
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>
> koen, could you check if it is easy to make g the last attribute ?  currently it seems to be systematically the first attribute.
> <process name="EndState" xmlns="http://jbpm.org/4/jpdl">
>   <start g="16,96,48,48">
>      <transition to="get return code" name=""/>
>   </start>
>   <state g="96,94,110,52" name="get return code">
>     <transition g="150,63:-36,11" name="200" to="ok"/>
>     <transition g=":-16,-27" name="400" to="bad request"/>
>     <transition g="150,177:-33,-32" name="500" to="internal server error"/>
>   </state>
>   <end g="239,40,48,48" name="ok" state="completed"/>
>   <end-cancel g="239,97,48,48" name="bad request"/>
>   <end-error g="240,154,48,48" name="internal server error"/>
> </process>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 10:00:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-308) prevent empty names
In-Reply-To: <7408830.1238663603004.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1750844506.1247493629200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-308:
--------------------------

    Component/s: jpdl


> prevent empty names
> -------------------
>
>                 Key: GPD-308
>                 URL: https://jira.jboss.org/jira/browse/GPD-308
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>
> in end state example, i see you generated an empty name.  that should be prevented if possible.  the fact that this still parses without exception is actually a bug.
> <process name="EndState" xmlns="http://jbpm.org/4/jpdl">
>   <start g="16,96,48,48">
>      <transition to="get return code" name=""/>
>   </start>
>   <state g="96,94,110,52" name="get return code">
>     <transition g="150,63:-36,11" name="200" to="ok"/>
>     <transition g=":-16,-27" name="400" to="bad request"/>
>     <transition g="150,177:-33,-32" name="500" to="internal server error"/>
>   </state>
>   <end g="239,40,48,48" name="ok" state="completed"/>
>   <end-cancel g="239,97,48,48" name="bad request"/>
>   <end-error g="240,154,48,48" name="internal server error"/>
> </process>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 10:02:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-312) activation.jar missing
In-Reply-To: <12405483.1239581002554.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <509026117.1247493749242.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-312.
---------------------------

    Resolution: Done


This is actually a problem in the 3.2.6 release of the runtime. It has been fixed in the meantime on the runtime.

> activation.jar missing
> ----------------------
>
>                 Key: GPD-312
>                 URL: https://jira.jboss.org/jira/browse/GPD-312
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM jPDL Designer 3.1.7
>            Reporter: Mauricio Salatino
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 3.1.8
>
>
> activation.jar missing, just remove the line that includes this jar in the file: src\resources\gpd\vesrion.info.xml, because if not this jar is needed in eclipse.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 10:02:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-313) sample project not
 create the sample process
In-Reply-To: <28112889.1239581122418.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1303924967.1247493749408.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-313.
---------------------------

    Resolution: Done


This is actually a problem om the jBPM 3.2.6 runtime. It has been fixed in the meantime.

> sample project not create the sample process
> --------------------------------------------
>
>                 Key: GPD-313
>                 URL: https://jira.jboss.org/jira/browse/GPD-313
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>    Affects Versions: jBPM jPDL Designer 3.1.7
>            Reporter: Mauricio Salatino
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 3.1.8
>
>
> the test and the action handler is created but the process is not created. This makes the example incomplete.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 10:04:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-309) CDATA sections in
 custom elements
 of actions with config-type="bean" cause a NPE in the jBPM GPD.
In-Reply-To: <27833917.1239352042648.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1942054259.1247493869187.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-309:
--------------------------

    Component/s: jpdl


> CDATA sections in custom elements of actions with config-type="bean" cause a NPE in the jBPM GPD.
> -------------------------------------------------------------------------------------------------
>
>                 Key: GPD-309
>                 URL: https://jira.jboss.org/jira/browse/GPD-309
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM jPDL Designer 3.1.6
>         Environment: Eclipse 3.4.1
>            Reporter: Roman Heinz
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 3.1.8
>
>
> CDATA sections in custom elements of actions with config-type="bean" cause a NPE in the jBPM GPD.
> <?xml version="1.0" encoding="UTF-8"?>
> <process-definition 
>   xmlns="urn:jbpm.org:jpdl-3.2"
>   name="simple">
>    <start-state name="start">
>       <transition name="to_state" to="first">
>       </transition>
>    </start-state>
>    <state name="first">
>         <event type="node-enter">
>             <action class="foo.Bar" name="fooAction" config-type="bean">
>                 <rowdocid><![CDATA[ Test ]]></rowdocid>
>             </action>
>         </event>
>       <transition name="to_end" to="end">
>       </transition>
>    </state>
>    <end-state name="end"></end-state>
> </process-definition>
> Result:
> java.lang.NullPointerException
> 	at org.jbpm.gd.common.xml.GenericElementXmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.common.xml.GenericElementXmlAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.common.xml.GenericElementXmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ActionDomAdapter.doModelAdd(Unknown Source)
> 	at org.jbpm.gd.common.xml.XmlAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.ActionDomAdapter.initialize(Unknown Source)
> 	at org.jbpm.gd.jpdl.xml.EventDomAdapter.doModelAdd(Unknown Source)
> ...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 10:21:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-347) <timer> tag in
 <transition> removed
Message-ID: <623466674.1247494889135.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-347.
---------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.0.GA
       Resolution: Done


> <timer> tag in <transition> removed
> -----------------------------------
>
>                 Key: GPD-347
>                 URL: https://jira.jboss.org/jira/browse/GPD-347
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>            Reporter: Johan Kumps
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>
> Consider a state like this :
> <state g="297,164,80,40" name="wait-partner">
> 	<transition g="-33,-18" name="updateReceived" to="end"/>
> 	<transition g="-41,-18" name="timeout" to="escalate-to-bis">
> 		<timer duedate="10 minutes"/>
> 	</transition>
> </state>
> When changing the layout of the process definition in the diagram view, the <timer> node is removed by GPD.
> <state g="297,164,80,40" name="wait-partner">
> 	<transition g="-33,-18" name="updateReceived" to="end"/>
> 	<transition g="-41,-18" name="timeout" to="escalate-to-bis">
> 	</transition>
> </state>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 10:25:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-344) Editing looses
 conditions assigned to transitions
In-Reply-To: <23880405.1243431145809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1577391470.1247495129191.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-344.
---------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.0.GA
       Resolution: Done


> Editing looses conditions assigned to transitions
> -------------------------------------------------
>
>                 Key: GPD-344
>                 URL: https://jira.jboss.org/jira/browse/GPD-344
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>         Environment: GPD from jbpm-4.0.0.Beta2
>            Reporter: Alexis Seigneurin
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.GA
>
>
> When you edit a process which has conditions attached to transitions, these conditions are lost if you edit using the graphical editor.
> I am using the DecisionConditions process taken from the documentation:
> <process name="DecisionConditions" >
>   <start>
>     <transition to="evaluate document" />
>   </start>
>   <decision name="evaluate document">
>     <transition to="submit document">
>       <condition expr="#{content=="good"}" />
>     </transition>
>     <transition to="try again">
>       <condition expr="#{content=="not so good"}" />
>     </transition>
>     <transition to="give up" />
>   </decision>
>   <state name="submit document" />
>   <state name="try again" />
>   <state name="give up" />
> </process>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 10:25:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-337) image clipping
In-Reply-To: <22840615.1242894476675.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <566797339.1247495129261.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-337:
--------------------------

    Component/s: jpdl


> image clipping
> --------------
>
>                 Key: GPD-337
>                 URL: https://jira.jboss.org/jira/browse/GPD-337
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> the generated images are too large.  clipping them would be nice to have.  
> watch out with clipping the top left corner (i assume that is coordinates 0,0).  if you clip that while saving the image, then the coordinates in the process, used by the console might be affected.  
> while clipping the bottom right  corner should be possible without problem for the console.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 10:27:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-302) Generate Form Dialog
 is NOT auto-populated with controller variables or named transitions
In-Reply-To: <25947797.1235964418319.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1001795206.1247495249216.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-302:
--------------------------

    Component/s: jpdl


> Generate Form Dialog is NOT auto-populated with controller variables or named transitions
> -----------------------------------------------------------------------------------------
>
>                 Key: GPD-302
>                 URL: https://jira.jboss.org/jira/browse/GPD-302
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM jPDL Designer 3.1.6
>         Environment: Eclipse 3.1.4 w/ jBPM 3.3.1.GA w/ GPD 3.1.6
>            Reporter: Noah N. O'Consequence
>            Assignee: Koen Aers
>            Priority: Minor
>
> The launched dialog of a task's "Generate Form..." button is NOT automatically populated with the task's defined controller variables nor with buttons that correspond to the task's named transitions.  This issue significantly hinders the usefulness of the GPD.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 10:31:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 13 Jul 2009 10:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7052) when invoked from
 remote client, 
 call to ManagementView.getComponentsForType() fails with
 "ClassNotFoundException:
 org.jboss.profileservice.management.ManagedOperationDelegate"
In-Reply-To: <28814772.1245791936832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1021536366.1247495489419.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer resolved JBAS-7052.
--------------------------------

    Resolution: Done


I tested last week - looks good now.


> when invoked from remote client, call to ManagementView.getComponentsForType() fails with "ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7052
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7052
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Ian Springer
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The ManagedOperationDelegate class is found in jboss-profileservice.jar and so should not be required on the client side.
> To reproduce this, the following client code can be used:
> https://svn.jboss.org/repos/jopr/trunk/modules/tools/jbas5-plugin-descriptor-gen/
> Just do:
> mvn install
> cd target
> java -jar jopr-jbas5-plugin-descriptor-gen-2.3.0-SNAPSHOT.jar
> Here's the stack trace:
> Exception in thread "main" java.lang.ClassNotFoundException: org.jboss.profileservice.management.ManagedOperationDelegate
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at java.util.HashSet.readObject(HashSet.java:291)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getComponentsForType(AOPProxy$1.java)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.addComponentsToDescriptor(PluginDescriptorGenerator.java:171)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.generatePluginDescriptor(PluginDescriptorGenerator.java:119)
>         at org.jboss.jopr.tool.jbas5.PluginDescriptorGenerator.main(PluginDescriptorGenerator.java:113)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 10:31:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-336) image generation fails
In-Reply-To: <18908917.1242894356480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1482320652.1247495489544.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-336:
--------------------------

    Component/s: jpdl


> image generation fails
> ----------------------
>
>                 Key: GPD-336
>                 URL: https://jira.jboss.org/jira/browse/GPD-336
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.0.x
>
>
> image generation seems to work for org.jbpm.examples.async.activity
> but it seems to fail for org.jbpm.examples.async.fork.  in that case I get an image with only a diagonal line.
> koen, do you get the same with that example ?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 10:38:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 13 Jul 2009 10:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2206) exists Foo()
 does not fire if facts inserted before rule
In-Reply-To: <1053908145.1247483549402.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <84572679.1247495909383.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned JBRULES-2206:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)


> exists Foo() does not fire if facts inserted before rule
> --------------------------------------------------------
>
>                 Key: JBRULES-2206
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2206
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Wolfgang Laun
>            Assignee: Edson Tirelli
>         Attachments: RuleTester.java, test1.drl, test2.drl
>
>
> Facts of some type Foo are inserted into a StatefulKnowledgeSession, then a rule with LHS exists Foo() is added and fireAllRules() is called, but the rule does not fire.
> If the same is done with the FOP-equivalent rule containing CE not(not Foo()), the rule fires.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 10:38:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 13 Jul 2009 10:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2206) exists Foo()
 does not fire if facts inserted before rule
In-Reply-To: <1053908145.1247483549402.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1833795392.1247495909597.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476039#action_12476039 ] 

Edson Tirelli commented on JBRULES-2206:
----------------------------------------

exists() and not(not()) should generate the exact same result. I will investigate. Thanks.

> exists Foo() does not fire if facts inserted before rule
> --------------------------------------------------------
>
>                 Key: JBRULES-2206
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2206
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Wolfgang Laun
>            Assignee: Edson Tirelli
>         Attachments: RuleTester.java, test1.drl, test2.drl
>
>
> Facts of some type Foo are inserted into a StatefulKnowledgeSession, then a rule with LHS exists Foo() is added and fireAllRules() is called, but the rule does not fire.
> If the same is done with the FOP-equivalent rule containing CE not(not Foo()), the rule fires.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 10:50:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 10:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-339) pageflow designer
In-Reply-To: <18436103.1242895977551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <980136580.1247496629265.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-339:
--------------------------

    Component/s: seam


> pageflow designer
> -----------------
>
>                 Key: GPD-339
>                 URL: https://jira.jboss.org/jira/browse/GPD-339
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: seam
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.x
>
>
> new version of the pageflow designer

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 10:50:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 13 Jul 2009 10:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2130) DSL Bug while
 creating comparison combinations
In-Reply-To: <17065276.1245415796493.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <331442502.1247496629372.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2130.
----------------------------------

    Fix Version/s: 5.1.0.M1
       Resolution: Rejected


This is not a bug. It is designed to be this way to allow grammar sentences chaining:

http://downloads.jboss.com/drools/docs/5.0.1.26597.FINAL/drools-expert/html_single/index.html#d0e5515

"You can chain DSL expressions together on one line, as long as it is clear to the parser what the {tokens} are (otherwise you risk reading in too much text until the end of the line). The DSL expressions are processed according to the mapping file, top to bottom in order. "

So, in case you don't want to chain the result of a sentence into another sentence, always write your most specific sentences first in the grammar file.

> DSL Bug while creating comparison combinations
> ----------------------------------------------
>
>                 Key: JBRULES-2130
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2130
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>         Environment: I tried building the DSL using Guvnor
>            Reporter: Prem Stephen
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> In http://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/docs/drools-expert/html_single/index.html#d0e5595, section 4.10.4 - I am expanding on the following syntax example for structuring combinations in the DSL.
> In my example, I have
> [when]There is a Contact with=Contact()
> [when]- age is less than {age}=age < {age}
> [when]- age is greater than {age}=age > {age}
> [when]- age is less than or equal to {age}=age <= {age}   <-------------------- this line does not work
> [when]- age is foo than or equal to {age}=age <= {age}
> and my rule is
> when
> 	There is a Contact with
> 	- age is foo than or equal to 35
> 	
> then
> 	Log : "Contact exists Test";
> Now, the line that does not work is because it shares the start "age is less than " with an earlier DSL.
> Replacing "less" with "foo" works for this reason.
> I think the parsing needs to be fixed to look at the whole sentence.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 10:52:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Mon, 13 Jul 2009 10:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-205) Provide a way to
 handle exceptions while doing check complete
In-Reply-To: <1231079725.1247493149630.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <246540573.1247496749200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBDEPLOY-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBDEPLOY-205.
----------------------------------

    Resolution: Done


> Provide a way to handle exceptions while doing check complete
> -------------------------------------------------------------
>
>                 Key: JBDEPLOY-205
>                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-205
>             Project: JBoss Deployers
>          Issue Type: Feature Request
>          Components: maindeployer
>    Affects Versions: JBDEPLOY-2.0.8.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For:  JBDEPLOY-2.2.x
>
>
> Allow for exception handling in Deployers::checkComplete.
> Introducing new ExceptionHandler interface.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 10:56:41 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 13 Jul 2009 10:56:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-216)
 SchemaBindingValidator: ordering inside choice shouldn't be required
Message-ID: <2050915512.1247497001857.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SchemaBindingValidator: ordering inside choice shouldn't be required
--------------------------------------------------------------------

                 Key: JBXB-216
                 URL: https://jira.jboss.org/jira/browse/JBXB-216
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.2.Beta1
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: JBossXB-2.0.2.GA


The validator currently checks the ordering of particles in choices.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 11:00:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-218) Create an online
 distribution for the designer
In-Reply-To: <243694.1215448946850.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1090871464.1247497229367.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-218.
---------------------------

    Resolution: Out of Date


> Create an online distribution for the designer
> ----------------------------------------------
>
>                 Key: GPD-218
>                 URL: https://jira.jboss.org/jira/browse/GPD-218
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>            Reporter: Thomas Diesler
>            Assignee: Koen Aers
>
> The designer should be installable from a remote site (i.e. an update url to the designer should be sufficient)
> http://subclipse.tigris.org/install.html
> http://m2eclipse.codehaus.org/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 11:04:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-37) include snap to grid
In-Reply-To: <30030403.1168963978540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1487524475.1247497469350.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-37.
--------------------------

    Resolution: Out of Date
      Assignee: Koen Aers


> include snap to grid
> --------------------
>
>                 Key: GPD-37
>                 URL: https://jira.jboss.org/jira/browse/GPD-37
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>
> While designing processes, it would be a lot easier if there is some kind of 'snap to grid'. You can then have easier manual allignment etc. Besides that, the images look better
> - transitions should snap to the grid to
> - transitions should be perpendicular at least if there are more than three points in the line 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 11:04:29 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 13 Jul 2009 11:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-216)
 SchemaBindingValidator: ordering inside choice shouldn't be required
In-Reply-To: <2050915512.1247497001857.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1202721619.1247497469448.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBXB-216.
----------------------------------

    Resolution: Done


Fixed.

> SchemaBindingValidator: ordering inside choice shouldn't be required
> --------------------------------------------------------------------
>
>                 Key: JBXB-216
>                 URL: https://jira.jboss.org/jira/browse/JBXB-216
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.2.Beta1
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossXB-2.0.2.GA
>
>
> The validator currently checks the ordering of particles in choices.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 11:10:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-352) unable to generate
 process image in jpdl4
In-Reply-To: <14071258.1244185257421.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <905124539.1247497829231.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-352.
---------------------------

    Fix Version/s: jBPM jPDL Designer 4.0.0.beta2
       Resolution: Done


> unable to generate process image in jpdl4
> -----------------------------------------
>
>                 Key: GPD-352
>                 URL: https://jira.jboss.org/jira/browse/GPD-352
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM jPDL Designer 4.0.0.beta1
>         Environment: windows xp
>            Reporter: maruthi pramod
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.0.0.beta2
>
>
> Hi,
> I am new to jbpm and we started R & D no jbpm4 beta version currently.i have requirement that i need to show the user by highlight the active state of the process .i am using jpdl4 1.0.0 beta version. but am unable to view or generate the image for process definitions for the new process definations or the for the examples provide by jbpm 4 beta version. and one more thing that i also unable to see the process image in GWT-console also . please provide some help on this issue.
> Thanks & regards 
> maruthi

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 11:13:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-74) Add a server adaptor
 to enable starting and stopping the 'jbpm server'.
In-Reply-To: <15710853.1178575432195.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <657311620.1247498009573.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-74.
--------------------------

    Resolution: Won't Fix


> Add a server adaptor to enable starting and stopping the 'jbpm server'.
> -----------------------------------------------------------------------
>
>                 Key: GPD-74
>                 URL: https://jira.jboss.org/jira/browse/GPD-74
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 11:17:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-357) Error while validating
 jPDL file: Problem class was moved from API
Message-ID: <985295068.1247498249570.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Error while validating jPDL file: Problem class was moved from API
------------------------------------------------------------------

                 Key: GPD-357
                 URL: https://jira.jboss.org/jira/browse/GPD-357
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM jPDL Designer 4.0.0.GA
            Reporter: Koen Aers
            Assignee: Koen Aers
             Fix For: jBPM jPDL Designer 4.1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 11:22:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-356) Designer creates
 duplicate handler nodes under decision nodes
In-Reply-To: <2099402771.1247492381837.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2044991389.1247498549152.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-356:
--------------------------

    Fix Version/s: jBPM jPDL Designer 4.1


> Designer creates duplicate handler nodes under decision nodes
> -------------------------------------------------------------
>
>                 Key: GPD-356
>                 URL: https://jira.jboss.org/jira/browse/GPD-356
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM jPDL Designer 4.0.0.GA
>            Reporter: Alfie Kirkpatrick
>            Assignee: Koen Aers
>            Priority: Minor
>             Fix For: jBPM jPDL Designer 4.1
>
>
> When switching between text mode and graphical mode and saving the process definition a few times a large number of handler elements can build up under each decision node. This doesn't seem to affect the running of the process so is more an inconvenience than anything, but could cause confusion if the handler parameters are modified.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 11:24:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-357) Error while validating
 jPDL file: Problem class was moved from API
In-Reply-To: <985295068.1247498249570.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <913107664.1247498669298.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-357:
--------------------------

    Component/s: jpdl


> Error while validating jPDL file: Problem class was moved from API
> ------------------------------------------------------------------
>
>                 Key: GPD-357
>                 URL: https://jira.jboss.org/jira/browse/GPD-357
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM jPDL Designer 4.0.0.GA
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 11:26:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (GPD-154) process image
 rendered incorrectly for large process definition
In-Reply-To: <2916967.1186754521287.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1610175395.1247498789400.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers reassigned GPD-154:
-----------------------------

    Assignee: Koen Aers  (was: Tom Baeyens)


> process image rendered incorrectly for large process definition
> ---------------------------------------------------------------
>
>                 Key: GPD-154
>                 URL: https://jira.jboss.org/jira/browse/GPD-154
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>         Environment: mac osx,  tomcat 5.0.28
>            Reporter: Ross McDonald
>            Assignee: Koen Aers
>            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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 11:26:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-207) For task
 creation/modification, 
 prepopulate form fields/buttons in 'Generate Task Form' from xhtml if file
 exists.
In-Reply-To: <24046624.1190992301165.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1172486335.1247498789669.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-207.
---------------------------

    Resolution: Won't Fix


> For task creation/modification, prepopulate form fields/buttons in 'Generate Task Form'  from xhtml if file exists.
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: GPD-207
>                 URL: https://jira.jboss.org/jira/browse/GPD-207
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>            Reporter: Chris Whalen
>            Assignee: Tom Baeyens
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 11:34:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-278) Security issue allows
 arbitrary java code to be deployed and executed
In-Reply-To: <28885895.1229329956636.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1644681387.1247499269388.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-278.
---------------------------

    Resolution: Rejected


As can be derived from the comments, this issue has nothing to do with the GPD. A sandbox system for the runtime is being put in place.

> Security issue allows arbitrary java code to be deployed and executed
> ---------------------------------------------------------------------
>
>                 Key: GPD-278
>                 URL: https://jira.jboss.org/jira/browse/GPD-278
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>            Reporter: Thomas Diesler
>            Assignee: Koen Aers
>            Priority: Critical
>
> The GPD circumvents the JBoss deployer architecture and hence allows arbitrary code to be executed on the AS

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 11:36:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-353) contribute xsd to xml
 catalog (xsd dependent on runtime)
In-Reply-To: <22572021.1244570156492.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <730805262.1247499389100.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers updated GPD-353:
--------------------------

    Fix Version/s: jBPM jPDL Designer 4.1
                       (was: jBPM jPDL Designer 4.x)


> contribute xsd to xml catalog (xsd dependent on runtime)
> --------------------------------------------------------
>
>                 Key: GPD-353
>                 URL: https://jira.jboss.org/jira/browse/GPD-353
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 11:38:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 13 Jul 2009 11:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-358) Create jBPM Project
 Configuration Wizard
Message-ID: <497794165.1247499509147.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Create jBPM Project Configuration Wizard
----------------------------------------

                 Key: GPD-358
                 URL: https://jira.jboss.org/jira/browse/GPD-358
             Project: JBoss jBPM GPD
          Issue Type: Task
          Components: jpdl
            Reporter: Koen Aers
            Assignee: Koen Aers
             Fix For: jBPM jPDL Designer 4.1


This wizard can be launched from the project popup menu in the Java/J2EE/Resources perspective. It will import all the libraries from the currently configured runtime.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 12:40:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Mon, 13 Jul 2009 12:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7085) Replace ejb3 secured
 profile service facade with secured remoting proxy
In-Reply-To: <1810173299.1247085411421.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <81658550.1247503229600.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7085:
---------------------------------

    Labels: profileservice  (was: )


> Replace ejb3 secured profile service facade with secured remoting proxy
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7085
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7085
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService, Security
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Its been decided to limit the number of dependencies an admin client needs to communicate with a secured profile service. We need to drop the ejb3 facade and provide a secured remoting based proxy bound in global jndi and an unsecured, but security manager controlled unsecured proxy under the java: local jndi namespace.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 12:40:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Mon, 13 Jul 2009 12:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7081)
 ConcurrentModificationException
 when invoking 'stop' managed operation on Queue managed component
In-Reply-To: <1715358388.1246912672146.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2037280426.1247503229433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7081:
---------------------------------

    Labels: profileservice  (was: )


> ConcurrentModificationException when invoking 'stop' managed operation on Queue managed component
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7081
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7081
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Here's the stack trace:
> Exception when invoking stop(): java.lang.reflect.UndeclaredThrowableException: Failed to invoke method 'stop' on component 'jboss.messaging.destination:name=ex
> ,service=Queue' with parameters [].
> Exception in thread "Thread-28" java.lang.RuntimeException: javax.ejb.EJBException: java.util.ConcurrentModificationException
>         at test.Worker.run(Worker.java:102)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: javax.ejb.EJBException: java.util.ConcurrentModificationException
>         at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:77)
>         at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)
>         at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
>         at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
>         at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
>         at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
>         at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
>         at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.util.ConcurrentModificationException
>         at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
>         at java.util.HashMap$EntryIterator.next(HashMap.java:834)
>         at java.util.HashMap$EntryIterator.next(HashMap.java:832)
>         at org.jboss.util.TimedCachePolicy.getValidKeys(TimedCachePolicy.java:364)
>         at org.jboss.virtual.plugins.cache.IterableTimedVFSCache.findContext(IterableTimedVFSCache.java:65)
>         at org.jboss.virtual.plugins.cache.CombinedVFSCache.findContext(CombinedVFSCache.java:116)
>         at org.jboss.virtual.plugins.registry.DefaultVFSRegistry.getFile(DefaultVFSRegistry.java:91)
>         at org.jboss.virtual.VFS.getRoot(VFS.java:200)
>         at org.jboss.profileservice.management.templates.JmsDestinationTemplate.applyTemplate(JmsDestinationTemplate.java:115)
>         at org.jboss.profileservice.management.AbstractTemplateCreator.applyTemplate(AbstractTemplateCreator.java:99)
>         at org.jboss.profileservice.management.ManagementViewImpl.applyTemplate(ManagementViewImpl.java:1362)
>         at sun.reflect.GeneratedMethodAccessor449.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
>         at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
>         at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:97)
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
>         at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$3.applyTemplate(AOPProxy$3.java)
>         at org.jboss.profileservice.ejb.SecureManagementView.applyTemplate(SecureManagementView.java:77)
>         at sun.reflect.GeneratedMethodAccessor446.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
>         at org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
>         at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
>         at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
>         at sun.reflect.GeneratedMethodAccessor386.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
>         at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_29585222.invoke(InvocationContextInterceptor_z_fillMet
> hod_29585222.java)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
>         at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_29585222.invoke(InvocationContextInterceptor_z_setup_295852
> 22.java)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
>         at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
>         at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
>         at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
>         at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
>         at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
>         at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$3.applyTemplate(AOPProxy$3.java)
>         at org.jboss.profileservice.ejb.SecureManagementView.applyTemplate(SecureManagementView.java:77)
>         at sun.reflect.GeneratedMethodAccessor446.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
>         at org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
>         at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
>         at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
>         at sun.reflect.GeneratedMethodAccessor386.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
>         at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_29585222.invoke(InvocationContextInterceptor_z_fillMet
> hod_29585222.java)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
>         at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_29585222.invoke(InvocationContextInterceptor_z_setup_295852
> 22.java)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
>         at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:421)
>         at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
>         at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
>         at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
>         at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
>         at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
>         at org.jboss.remoting.Client.invoke(Client.java:1724)
>         at org.jboss.remoting.Client.invoke(Client.java:629)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.applyTemplate(Unknown Source)
>         at test.Worker.run(Worker.java:93)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
>         at $Proxy7.invoke(Unknown Source)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
>         at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
>         at $Proxy4.applyTemplate(Unknown Source)
>         at test.Worker.run(Worker.java:93)
>         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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 12:42:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Mon, 13 Jul 2009 12:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7072) Don't write a URL
 for host 0.0.0.0 in jnp-service.url
In-Reply-To: <15437469.1246547091499.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1234298219.1247503349124.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7072:
---------------------------------

    Labels: profileservice  (was: )


> Don't write a URL for host 0.0.0.0 in jnp-service.url
> -----------------------------------------------------
>
>                 Key: JBAS-7072
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7072
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services, Naming
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> See JOPR-254 for an explanation of the issue. This issue is to ensure NamingServiceURLWriter writes the correct URL.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 12:45:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Mon, 13 Jul 2009 12:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7050)
 "ClassNotFoundException:
 org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote
 calls to ManagementView.getTemplate()
Message-ID: <1161766619.1247503529754.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476068#action_12476068 ] 

Charles Crouch commented on JBAS-7050:
--------------------------------------

Lukas can you test please.

> "ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote calls to ManagementView.getTemplate()
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7050
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7050
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Lukas Krejci
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to create a datasource in AS5 using JON, the following exception occurs:
> java.lang.ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo                                                                                               
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)                                                                                            
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)                                                                                                 
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)                                                                                                                         
>         at java.lang.Class.forName0(Native Method)                                                                                                                                               
>         at java.lang.Class.forName(Class.java:247)                                                                                                                                               
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)                                                                   
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)                                                                                                               
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)                                                                                                                  
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)                                                                                                  
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)                                                                                                               
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)                                                                                                              
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)                                                                                                                 
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)                                                        
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)                                                                  
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)                                                                              
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)                                                                                     
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)                                                                        
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)                                                                             
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)                                                                                                 
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                                    
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                                     
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                            
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                          
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                        
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)                                                                                                                
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)                                                             
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> I was only able to find this class in jboss-embedded-all maven module.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 12:45:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Mon, 13 Jul 2009 12:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7050)
 "ClassNotFoundException:
 org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote
 calls to ManagementView.getTemplate()
Message-ID: <2017550790.1247503529435.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7050:
---------------------------------

    Assignee: Lukas Krejci  (was: Scott M Stark)


> "ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote calls to ManagementView.getTemplate()
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7050
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7050
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Lukas Krejci
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to create a datasource in AS5 using JON, the following exception occurs:
> java.lang.ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo                                                                                               
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)                                                                                            
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)                                                                                                 
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)                                                                                                                         
>         at java.lang.Class.forName0(Native Method)                                                                                                                                               
>         at java.lang.Class.forName(Class.java:247)                                                                                                                                               
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)                                                                   
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)                                                                                                               
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)                                                                                                                  
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)                                                                                                  
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)                                                                                                               
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)                                                                                                              
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)                                                                                                                 
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)                                                        
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)                                                                  
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)                                                                              
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)                                                                                     
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)                                                                        
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)                                                                             
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)                                                                                                 
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                                    
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                                     
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                            
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                          
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                        
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)                                                                                                                
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)                                                             
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> I was only able to find this class in jboss-embedded-all maven module.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 12:47:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Mon, 13 Jul 2009 12:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-7050)
 "ClassNotFoundException:
 org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote
 calls to ManagementView.getTemplate()
Message-ID: <1174532460.1247503649370.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch reopened JBAS-7050:
----------------------------------



> "ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote calls to ManagementView.getTemplate()
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7050
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7050
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Lukas Krejci
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to create a datasource in AS5 using JON, the following exception occurs:
> java.lang.ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo                                                                                               
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)                                                                                            
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)                                                                                                 
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)                                                                                                                         
>         at java.lang.Class.forName0(Native Method)                                                                                                                                               
>         at java.lang.Class.forName(Class.java:247)                                                                                                                                               
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)                                                                   
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)                                                                                                               
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)                                                                                                                  
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)                                                                                                  
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)                                                                                                               
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)                                                                                                              
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)                                                                                                                 
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)                                                        
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)                                                                  
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)                                                                              
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)                                                                                     
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)                                                                        
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)                                                                             
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)                                                                                                 
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                                    
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                                     
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                            
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                          
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                        
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)                                                                                                                
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)                                                             
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> I was only able to find this class in jboss-embedded-all maven module.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 14:38:29 2009
From: jira-events at lists.jboss.org (Gurkan Erdogdu (JIRA))
Date: Mon, 13 Jul 2009 14:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-112) Adding Partial
 Implementation for Specification Chapter11
In-Reply-To: <546837010.1247330860697.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1794605417.1247510309274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gurkan Erdogdu updated JBJCA-112:
---------------------------------

    Attachment: CommonProject.patch
                CoreProject.patch
                CoreProjectTest.patch


Re-attached after running checkstyle tool and update accordingly.

> Adding Partial Implementation for Specification Chapter11
> ---------------------------------------------------------
>
>                 Key: JBJCA-112
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-112
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Core
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>         Attachments: CommonProject.diff, CommonProject.patch, CoreProject.diff, CoreProject.patch, CoreProjectTest.patch, CoreTest.diff
>
>
> I have implemented some of checks that are defined in the specification Chapter 11.
> 3 different patches exist
> 1* CommonProject.diff --> Contains utility class.
> 2* CoreProject.diff --> Updating WorkWrapper and WorkManagerImpl to support WorkContextProvider
> 3* CoreTest.diff --> Updating tests for Chapter 11

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 15:19:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Mon, 13 Jul 2009 15:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <311041377.1247512769473.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch reopened JBAS-6185:
----------------------------------



Good stuff Scott
Can you just note down what tests you executed/added to the testsuite for this issue?
Thanks

> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Scott Marlow
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 15:37:41 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 13 Jul 2009 15:37:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6970)
 org.jboss.test.profileservice.test.ProfileServiceUnitTestCase failing with
 IBM JDK
In-Reply-To: <14973284.1243005236696.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <213677985.1247513861375.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-6970.
----------------------------------

    Resolution: Done


This is no longer reproducable running locally or as seen in the latest Hudson run:
http://hudson.qa.jboss.com/hudson/view/EAP-CI/job/JBoss-EAP-5.0.x-Testsuite-ibm16/lastBuild/testReport/org.jboss.test.profileservice.test/ProfileServiceUnitTestCase(profileservice)/

> org.jboss.test.profileservice.test.ProfileServiceUnitTestCase failing with IBM JDK
> ----------------------------------------------------------------------------------
>
>                 Key: JBAS-6970
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6970
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: javacore.20090522.171654.29389.0003.txt, profileservice-test.log
>
>
> The org.jboss.test.profileservice.test.ProfileServiceUnitTestCase testcase fails with the following error:
> Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit.
> junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit.
> In the test log you can see this:
> one-test:
>    [delete] Deleting: /home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/log/test.log
>     [junit] Running org.jboss.test.profileservice.test.ProfileServiceUnitTestCase
>     [junit] Unhandled exception
>     [junit] Type=Segmentation error vmState=0x00040000
>     [junit] J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
>     [junit] Handler1=F7F8961B Handler2=F7F4E2CC InaccessibleAddress=D51E5488
>     [junit] EDI=0A0D7E78 ESI=00000003 EAX=FFAEC4A4 EBX=0A02E818
>     [junit] ECX=FFAEC4A4 EDX=D51E547C
>     [junit] EIP=F7F867D3 ES=0000002B DS=0000002B ESP=FFAEC46C
>     [junit] EFlags=00210296 CS=FFAE0023 SS=0004002B EBP=FFAEC474
>     [junit] Module=/mnt/jqa/ibm-java2-i386-50/jre/bin/libj9vm23.so
>     [junit] Module_base_address=F7F63000
>     [junit] Target=2_30_20081126_26240_lHdSMr (Linux 2.6.18-92.1.22.el5)
>     [junit] CPU=x86 (8 logical CPUs) (0x1f75ed000 RAM)
>     [junit] JVMDUMP006I Processing Dump Event "gpf", detail "" - Please Wait.
>     [junit] JVMDUMP007I JVM Requesting System Dump using '/home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/core.20090522.170741.29133.0001.dmp'
>     [junit] JVMDUMP010I System Dump written to /home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/core.20090522.170741.29133.0001.dmp
>     [junit] JVMDUMP007I JVM Requesting Snap Dump using '/home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/Snap.20090522.170741.29133.0002.trc'
>     [junit] JVMDUMP010I Snap Dump written to /home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/Snap.20090522.170741.29133.0002.trc
>     [junit] JVMDUMP007I JVM Requesting Java Dump using '/home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/javacore.20090522.170741.29133.0003.txt'
>     [junit] JVMDUMP010I Java Dump written to /home/brq/mmalina/jbossqa/ibm/jboss-5.1.0.CR1-src/testsuite/output/javacore.20090522.170741.29133.0003.txt
>     [junit] JVMDUMP013I Processed Dump Event "gpf", detail "".
>     [junit] Running org.jboss.test.profileservice.test.ProfileServiceUnitTestCase
>     [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
>     [junit] Test org.jboss.test.profileservice.test.ProfileServiceUnitTestCase FAILED (crashed)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 15:40:29 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 13 Jul 2009 15:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6936) Testsuite fails
 during
 tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
In-Reply-To: <368622.1242662765255.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1073615533.1247514029217.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6936:
---------------------------------


I'm going to exclude the org.jboss.test.deployers.seam.test.SeamBookingExampleUnitTestCase and
org.jboss.test.deployers.seam.test.SeamJpaExampleUnitTestCase so we can get in a full test run with IBM JDK 6. 
There are additional issues updating the examples to use 2.1.2.CR1 or higher which contains RF 3.3.0 and the resolution
to the issue noted above.

> Testsuite fails during tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6936
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6936
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: threadDump.html
>
>
> The AS fails to start for the second time during the tests-profileservice target of the testsuite. This is caused by the first instance not being properly shutdown by the following ant command: <server:stop name="profileservice"/>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 15:42:41 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 13 Jul 2009 15:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6969)
 org.jboss.test.profileservice.override.test.JmsDestinationOverrideTestCase
 failing with IBM JDK
In-Reply-To: <24863112.1243004277549.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <759026936.1247514161308.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-6969.
----------------------------------

    Resolution: Done


This is no longer reproducable running the tests locally or as seen in the latest Hudson run:
http://hudson.qa.jboss.com/hudson/view/EAP-CI/job/JBoss-EAP-5.0.x-Testsuite-ibm16/lastBuild/testReport/org.jboss.test.profileservice.override.test/

> org.jboss.test.profileservice.override.test.JmsDestinationOverrideTestCase failing with IBM JDK
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6969
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6969
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5 & 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: TEST-org.jboss.test.profileservice.override.test.JmsDestinationOverrideTestCase-profileservice.xml
>
>
> All the 3 tests of org.jboss.test.profileservice.override.test.JmsDestinationOverrideTestCase fail with this error message:
> org.jboss.jms.server.destination.QueueServiceMO
> java.lang.ClassNotFoundException: org.jboss.jms.server.destination.QueueServiceMO
> 	at java.lang.Class.forName(Class.java:163)
> 	at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1568)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1490)
> 	at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1457)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1312)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1932)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1856)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1743)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1932)
> ...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 16:20:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 13 Jul 2009 16:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7095) HA Web Sessions via
 Database Persistence
Message-ID: <1302881808.1247516429179.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

HA Web Sessions via Database Persistence
----------------------------------------

                 Key: JBAS-7095
                 URL: https://jira.jboss.org/jira/browse/JBAS-7095
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Clustering, Web (Tomcat) service
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: JBossAS-5.2.0.Beta1


Occasionally we receive input from the JBoss AS user community that they'd like to see an option to use database persistence as a mechanism to make web sessions highly available. The basic use case we here for this is environments where sessions need to be available to AS instances located across a WAN. JBoss Cache/JGroups clusters can span a WAN but often users find it impractical to configure their cluster(s) in that way. However, their IT infrastructure already supports making RDBMS data accessible across the WAN. So, persisting sessions to the DB makes them available across the WAN.

This JIRA is to create a session Manager impl that satisfies this request. It will be based on the distributed session manager code that we use with JBoss Cache replication, but the implementation of the DistributedCacheManager SPI that manager uses will be replaced with a version the interacts with a RDMBS.

See http://www.jboss.org/community/wiki/HAWebSessionsviaDatabasePersistence for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 16:28:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 13 Jul 2009 16:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-112) Adding Partial
 Implementation for Specification Chapter11
In-Reply-To: <546837010.1247330860697.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <798181065.1247516909332.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-112.
-----------------------------------

    Fix Version/s: 1.0.0.Alpha2
       Resolution: Done


> Adding Partial Implementation for Specification Chapter11
> ---------------------------------------------------------
>
>                 Key: JBJCA-112
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-112
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Core
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>         Attachments: CommonProject.diff, CommonProject.patch, CoreProject.diff, CoreProject.patch, CoreProjectTest.patch, CoreTest.diff
>
>
> I have implemented some of checks that are defined in the specification Chapter 11.
> 3 different patches exist
> 1* CommonProject.diff --> Contains utility class.
> 2* CoreProject.diff --> Updating WorkWrapper and WorkManagerImpl to support WorkContextProvider
> 3* CoreTest.diff --> Updating tests for Chapter 11

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 16:44:29 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 13 Jul 2009 16:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <692918536.1247517869574.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476123#action_12476123 ] 

Scott Marlow commented on JBAS-6185:
------------------------------------

I did not add any tests to the testsuite for this issue.  My steps to test:

1.  Remove current server from jbossas/build/output/*

2.  cd jbossas dev folder

3.  Do a clean build
     ./build.sh clean

4.  Build the as
     ./build.sh

5.  Change into the generated server bin folder
     cd build/output/jboss-6.0.0.Alpha1/bin

6.  Append the following lines to run.conf (as mentioned in the documentation link above)
 JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote"
 JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"
 JAVA_OPTS="$JAVA_OPTS -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl"

7.  Start the as 
    ./run.sh

8.  After server starts, run jconsole (should be in jdk/bin folder)
    jconsole

9.  In the JConsole program, choose the just started as process from the "New Connection/Local Process" dialog and click the "connect" button.  

10.  Click on the MBeans tab, you should see the familar JBoss.* mbeans and the built in ones too (java.lang + com.sun).



> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Scott Marlow
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 17:59:29 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Mon, 13 Jul 2009 17:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7085) Replace ejb3
 secured profile service facade with secured remoting proxy
In-Reply-To: <1810173299.1247085411421.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <807244512.1247522369224.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBAS-7085.
---------------------------------

    Resolution: Done


This has been done. Note that the profileservice-jboss-beans.xml ProxyFactory bean has a createEjb3Links property which links the remoting proxy bindings to the old ejb3 facade names:

        <!-- Create links from secured proxies back to old secured ejb3 facades -->
        <property name="createEjb3Links">true</property>


> Replace ejb3 secured profile service facade with secured remoting proxy
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7085
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7085
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService, Security
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Its been decided to limit the number of dependencies an admin client needs to communicate with a secured profile service. We need to drop the ejb3 facade and provide a secured remoting based proxy bound in global jndi and an unsecured, but security manager controlled unsecured proxy under the java: local jndi namespace.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 19:01:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 13 Jul 2009 19:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-7085) Replace ejb3
 secured profile service facade with secured remoting proxy
In-Reply-To: <1810173299.1247085411421.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <942506613.1247526089361.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer reopened JBAS-7085:
--------------------------------



Can you summarize what the JNDI binding names are for:

1) the remote AOP proxy(s)
2) the local java:* unsecured proxy

Also, can you confirm that authentication is enabled by default for the AOP proxy and also describe the configuration steps for turning authentication on and off for it?


> Replace ejb3 secured profile service facade with secured remoting proxy
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7085
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7085
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService, Security
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Its been decided to limit the number of dependencies an admin client needs to communicate with a secured profile service. We need to drop the ejb3 facade and provide a secured remoting based proxy bound in global jndi and an unsecured, but security manager controlled unsecured proxy under the java: local jndi namespace.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 20:43:29 2009
From: jira-events at lists.jboss.org (Richard Taylor (JIRA))
Date: Mon, 13 Jul 2009 20:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7096) SLSB with dependency
 on
 HASingletonDeployer / Barrier results in error message on second node on
 startup
Message-ID: <1291600071.1247532209260.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SLSB with dependency on HASingletonDeployer / Barrier results in error message on second node on startup
--------------------------------------------------------------------------------------------------------

                 Key: JBAS-7096
                 URL: https://jira.jboss.org/jira/browse/JBAS-7096
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: JBossAS-5.1.0.GA
         Environment: RHEL 4 Update 7 (and OSX 10.5.7), Sun JRE 1.6.0_12, JBoss 5.1.0 - "all" configuration
            Reporter: Richard Taylor
            Assignee: Brian Stansberry
            Priority: Minor


Basic cluster, two JBoss 5.1.0 nodes, "all" configuration.   First node starts fine.  Second node starts, however at the end of starting, any SLSBs that depend on the barrier result in an error being logged at startup (on the second node). 

Example:
DEPLOYMENTS MISSING DEPENDENCIES:
  Deployment "jboss.j2ee:ear=app-ear.ear,jar=app-ejb.jar,name=BoardPollerMDB,service=EJB3" is missing the following dependencies:
    Dependency "<UNKNOWN jboss.j2ee:ear=app-ear.ear,jar=app-ejb.jar,name=BoardPollerMDB,service=EJB3>" (should be in state "Described", bu
t is actually in state "** UNRESOLVED Demands 'jboss.ha:service=HASingletonDeployer,type=Barrier' **")

DEPLOYMENTS IN ERROR:
  Deployment "<UNKNOWN jboss.j2ee:ear=app-ear.ear,jar=app-ejb.jar,name=BoardPollerMDB,service=EJB3>" is in error due to the following reas
on(s): ** UNRESOLVED Demands 'jboss.ha:service=HASingletonDeployer,type=Barrier' **

The SLSBs on node 2 do properly start in a failover scenario when node 1 goes down.  So functionally things seem OK.  However the error message is a little concerning and it leaves us wondering if there is more to the problem.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 22:39:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 13 Jul 2009 22:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1683) Create a tag
 porting the fix for JBMESSAGING-1682 to JBM 1.4.0.SP3-CP08
Message-ID: <227653208.1247539169302.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Create a tag porting the fix for JBMESSAGING-1682 to JBM 1.4.0.SP3-CP08
-----------------------------------------------------------------------

                 Key: JBMESSAGING-1683
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1683
             Project: JBoss Messaging
          Issue Type: Task
          Components: Messaging Core
    Affects Versions: 1.4.0.SP3.CP08
            Reporter: Howard Gao
            Assignee: Howard Gao
            Priority: Critical




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 22:55:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 13 Jul 2009 22:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1614) Remove 256
 bridge limitation
In-Reply-To: <11637338.1241212966583.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2060242541.1247540129514.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476140#action_12476140 ] 

Howard Gao commented on JBMESSAGING-1614:
-----------------------------------------

Note:

Due to JBMESSAGING-1682, the limit of node ID has been changed to 1023.


> Remove 256 bridge limitation
> ----------------------------
>
>                 Key: JBMESSAGING-1614
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1614
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Justin Bertram
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP08, 1.4.4.GA
>
>
> Currently JBoss Messaging limits bridges to 256 just like it does for cluster nodes because each bridge participant has to have a unique ServerPeerID (an 8-bit value).  However, users may want to bridge more than 256 servers to a single host.  Can this constraint be removed for bridges?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 13 23:56:29 2009
From: jira-events at lists.jboss.org (Mikheil Kapanadze (JIRA))
Date: Mon, 13 Jul 2009 23:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-912) ejb-jar.xml
 injected EntityManger fails in @PostConstruct annotated methods
In-Reply-To: <3249388.1173877358210.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <288694785.1247543789195.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476143#action_12476143 ] 

Mikheil Kapanadze commented on EJBTHREE-912:
--------------------------------------------

Hello,

Is this bug still not fixed? I have the same problem in JBoss 4.2.3GA
JDK 1.6 on Windows XP

Entity Manager is injected as 

@PersistenceContext(unitName = "MyUnit", type = PersistenceContextType.EXTENDED)
private EntityManager entityManager;

The following statement fails in method, annotated by @PostConstruct:
Query query = entityManager.createQuery("some-query-here");

Here is the exception from JBoss log file:

07:48:15,187 ERROR [STDERR] java.lang.RuntimeException: java.lang.NullPointerException
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.interceptor.LifecycleInterceptorHandler.postConstruct(LifecycleInterceptorHandler.java:113)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.EJBContainer.invokePostConstruct(EJBContainer.java:623)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.AbstractPool.create(AbstractPool.java:131)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.InfinitePool.get(InfinitePool.java:49)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.ThreadlocalPool.create(ThreadlocalPool.java:50)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.ThreadlocalPool.get(ThreadlocalPool.java:90)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:315)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:320)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.remoting.IsLocalInterceptor.invokeLocal(IsLocalInterceptor.java:81)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:72)
07:48:15,187 ERROR [STDERR] 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulRemoteProxy.invoke(StatefulRemoteProxy.java:139)
07:48:15,187 ERROR [STDERR] 	at $Proxy94.getCustomer(Unknown Source)
07:48:15,187 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
07:48:15,187 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
07:48:15,187 ERROR [STDERR] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
07:48:15,187 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Method.java:597)
07:48:15,187 ERROR [STDERR] 	at javax.el.BeanELResolver.getValue(BeanELResolver.java:62)
07:48:15,187 ERROR [STDERR] 	at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
07:48:15,187 ERROR [STDERR] 	at com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:72)
07:48:15,187 ERROR [STDERR] 	at org.apache.el.parser.AstValue.getValue(AstValue.java:97)
07:48:15,187 ERROR [STDERR] 	at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
07:48:15,187 ERROR [STDERR] 	at com.sun.faces.application.ValueBindingValueExpressionAdapter.getValue(ValueBindingValueExpressionAdapter.java:113)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.bean.FacesBeanImpl.getProperty(FacesBeanImpl.java:66)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.ValueRenderer.getValue(ValueRenderer.java:83)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.ValueRenderer.getConvertedString(ValueRenderer.java:51)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.OutputTextRenderer.encodeAll(OutputTextRenderer.java:68)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:224)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:711)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.render.RenderUtils.encodeRecursive(RenderUtils.java:70)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:299)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:321)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer.renderContent(PanelPartialRootRenderer.java:64)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.BodyRenderer.renderContent(BodyRenderer.java:138)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer.encodeAll(PanelPartialRootRenderer.java:119)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.BodyRenderer.encodeAll(BodyRenderer.java:78)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:335)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.DocumentRenderer.encodeAll(DocumentRenderer.java:80)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:224)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:711)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.component.UIXComponentBase.__encodeRecursive(UIXComponentBase.java:1280)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeAll(UIXComponentBase.java:731)
07:48:15,187 ERROR [STDERR] 	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:942)
07:48:15,187 ERROR [STDERR] 	at com.sun.faces.application.ViewHandlerImpl.doRenderView(ViewHandlerImpl.java:271)
07:48:15,187 ERROR [STDERR] 	at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:202)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:182)
07:48:15,187 ERROR [STDERR] 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:109)
07:48:15,187 ERROR [STDERR] 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
07:48:15,187 ERROR [STDERR] 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
07:48:15,187 ERROR [STDERR] 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:250)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:207)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:161)
07:48:15,187 ERROR [STDERR] 	at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
07:48:15,187 ERROR [STDERR] 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
07:48:15,187 ERROR [STDERR] 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
07:48:15,187 ERROR [STDERR] 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
07:48:15,187 ERROR [STDERR] 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
07:48:15,187 ERROR [STDERR] 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
07:48:15,187 ERROR [STDERR] 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
07:48:15,187 ERROR [STDERR] 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
07:48:15,187 ERROR [STDERR] 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
07:48:15,187 ERROR [STDERR] 	at java.lang.Thread.run(Thread.java:619)
07:48:15,187 ERROR [STDERR] Caused by: java.lang.NullPointerException
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.entity.ExtendedEntityManager.getPersistenceContext(ExtendedEntityManager.java:56)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.entity.ExtendedEntityManager.createQuery(ExtendedEntityManager.java:126)
07:48:15,187 ERROR [STDERR] 	at ge.ewallet.core.service.console.ConsoleManagerService.postConstruct(ConsoleManagerService.java:32)
07:48:15,187 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
07:48:15,187 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
07:48:15,187 ERROR [STDERR] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
07:48:15,187 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Method.java:597)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.interceptor.LifecycleInvocationContextImpl.proceed(LifecycleInvocationContextImpl.java:159)
07:48:15,187 ERROR [STDERR] 	at org.jboss.ejb3.interceptor.LifecycleInterceptorHandler.postConstruct(LifecycleInterceptorHandler.java:109)
07:48:15,187 ERROR [STDERR] 	... 73 more

> ejb-jar.xml injected EntityManger fails in @PostConstruct annotated methods
> ---------------------------------------------------------------------------
>
>                 Key: EJBTHREE-912
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-912
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - Patch 1
>         Environment: Identified on jboss-4.0.5.GA from jems installer 1.2.GA, still present in head from svn co http://anonsvn.jboss.org/repos/jbossas/branches/Branch_4_0/  as of 13th March 2007.  Tests run agains JDK 1.5 on Win XP (sp2)
>            Reporter: Andrew Redhead
>         Attachments: build-test.xml, resources-xmleminjection.zip, src-xmleminjection.zip, xmleminjection-pu-test.jar, xmleminjection-test.jar
>
>
> Using an ejb-jar.xml file to inject an EntityManger into an EJB3 stateless session bean succeeds for bean interface methods but fails for @PostConstruct methods.
> In both cases the reference to the EntityManager is non-null, however in the @PostConstruct method, accessing the EnityManger underlying delegate fails.
> The test cases provide both an "API" interface case (which passes) and an @PostConstruct case, which currently fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 02:40:29 2009
From: jira-events at lists.jboss.org (Alexander Marktl (JIRA))
Date: Tue, 14 Jul 2009 02:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1684) Message
 remain in the queue and do not get dispatched
Message-ID: <1603937672.1247553629290.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Message remain in the queue and do not get dispatched
-----------------------------------------------------

                 Key: JBMESSAGING-1684
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1684
             Project: JBoss Messaging
          Issue Type: Quality Risk
         Environment: SuSe Linux Enterprise Server 10, Java 1.5.0_11, AS 5 with JBoss Messaging - default installation
            Reporter: Alexander Marktl
            Assignee: Tim Fox
            Priority: Minor


I tried to create 10 queues and send 10.000 messages per queue from a single producer per queue to a single consumer per queue. Unfortunately  not all of the messages where delivered, some messages remain in the queues and wait for delivery. The JMX console for example states: 3 messages in the queue, 3 messages pending for delivery. But nothing happens. My receivers don't get these last messages. I don't know if this is a configuration issue or a bug. 

The queues are named: qname_0 ...qname_n





-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 02:45:29 2009
From: jira-events at lists.jboss.org (Alexander Marktl (JIRA))
Date: Tue, 14 Jul 2009 02:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1684) Message
 remain in the queue and do not get dispatched
In-Reply-To: <1603937672.1247553629290.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2027671497.1247553929324.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Marktl updated JBMESSAGING-1684:
------------------------------------------

    Attachment: jms-provider-evaluation.zip


The zip file contains the eclipse project i use for evaluating jms providers.
To run the test use the classes: StartMultipleMessageListener and StartMultipleMessageProducers which can be found in the ssi/jms/simple/general/starttests package. 
For the field companyname use "JBOSS" all in uppercase.
Run the MessageListeners first and then start up the Message Producers.

> Message remain in the queue and do not get dispatched
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1684
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1684
>             Project: JBoss Messaging
>          Issue Type: Quality Risk
>         Environment: SuSe Linux Enterprise Server 10, Java 1.5.0_11, AS 5 with JBoss Messaging - default installation
>            Reporter: Alexander Marktl
>            Assignee: Tim Fox
>            Priority: Minor
>         Attachments: jms-provider-evaluation.zip
>
>
> I tried to create 10 queues and send 10.000 messages per queue from a single producer per queue to a single consumer per queue. Unfortunately  not all of the messages where delivered, some messages remain in the queues and wait for delivery. The JMX console for example states: 3 messages in the queue, 3 messages pending for delivery. But nothing happens. My receivers don't get these last messages. I don't know if this is a configuration issue or a bug. 
> The queues are named: qname_0 ...qname_n

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 03:10:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 14 Jul 2009 03:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1684) Message
 remain in the queue and do not get dispatched
In-Reply-To: <1603937672.1247553629290.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1433895747.1247555429858.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1684:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> Message remain in the queue and do not get dispatched
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1684
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1684
>             Project: JBoss Messaging
>          Issue Type: Quality Risk
>         Environment: SuSe Linux Enterprise Server 10, Java 1.5.0_11, AS 5 with JBoss Messaging - default installation
>            Reporter: Alexander Marktl
>            Assignee: Howard Gao
>            Priority: Minor
>         Attachments: jms-provider-evaluation.zip
>
>
> I tried to create 10 queues and send 10.000 messages per queue from a single producer per queue to a single consumer per queue. Unfortunately  not all of the messages where delivered, some messages remain in the queues and wait for delivery. The JMX console for example states: 3 messages in the queue, 3 messages pending for delivery. But nothing happens. My receivers don't get these last messages. I don't know if this is a configuration issue or a bug. 
> The queues are named: qname_0 ...qname_n

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 03:47:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 14 Jul 2009 03:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1683) Create a tag
 porting the fix for JBMESSAGING-1682 to JBM 1.4.0.SP3-CP08
In-Reply-To: <227653208.1247539169302.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1524598028.1247557649284.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1683.
-----------------------------------

    Resolution: Done


Done. tag created:

https://svn.jboss.org/repos/messaging/tags/JBossMessaging_1_4_0_SP3_CP08.patch01/

> Create a tag porting the fix for JBMESSAGING-1682 to JBM 1.4.0.SP3-CP08
> -----------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1683
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1683
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>            Priority: Critical
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 04:50:43 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 14 Jul 2009 04:50:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1831) Clean up
	dependency chains
In-Reply-To: <13433231.1242136368008.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <93276200.1247561443067.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1831:
-----------------------------------

    Fix Version/s: 1.1.10
                       (was: 1.1.9)


> Clean up dependency chains
> --------------------------
>
>                 Key: EJBTHREE-1831
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1831
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: as-int, ejb3
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.10
>
>
> The true order should be:
> jboss-ejb3 > as-int > AS
> jboss-ejb3 > Plugin
> Whereas now as-int goes into Plugin.  Also endpoint-deployer should be included in as-int and Plugin, and not explicitly declared by AS itself.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 04:54:41 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 14 Jul 2009 04:54:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1814)
 NoPassivationCache does not obey maxSize
In-Reply-To: <17499438.1240909569920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <824983734.1247561681423.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1814:
-----------------------------------

    Fix Version/s: 1.1.10
                       (was: 1.1.9)


> NoPassivationCache does not obey maxSize
> ----------------------------------------
>
>                 Key: EJBTHREE-1814
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1814
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: cache
>            Reporter: Carlo de Wolf
>             Fix For: 1.1.10
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 06:26:29 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 14 Jul 2009 06:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1814)
 NoPassivationCache does not obey maxSize
In-Reply-To: <17499438.1240909569920.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1129313111.1247567189485.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf updated EJBTHREE-1814:
------------------------------------

    Fix Version/s:     (was: 1.1.10)


> NoPassivationCache does not obey maxSize
> ----------------------------------------
>
>                 Key: EJBTHREE-1814
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1814
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: cache
>            Reporter: Carlo de Wolf
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 06:35:30 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ville_Skytt=C3=A4_=28JIRA=29?=)
Date: Tue, 14 Jul 2009 06:35:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1701)
 getTimerService() can no longer be called in @Service start()
In-Reply-To: <2268578.1233053864441.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <825161588.1247567730223.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476173#action_12476173 ] 

Ville Skytt? commented on EJBTHREE-1701:
----------------------------------------

Another forum reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=158378

Any progress on this?

> getTimerService() can no longer be called in @Service start()
> -------------------------------------------------------------
>
>                 Key: EJBTHREE-1701
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1701
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: trunk
>         Environment: 5.0.0.GA
>            Reporter: Matt C
>            Assignee: Andrew Lee Rubinger
>         Attachments: EJBTHREE-1701_testcase_v1.patch, EJBTHREE-1701_testcase_v2.patch
>
>
> Calling getTimerService() is no longer allowed from the lifecycle methods of @Service.
> Exception java.lang.IllegalStateException: getTimerService() not allowed during injection (EJB3 4.5.2).
> This occurs in the start() method of a @Service bean. The effect is to disallow setup of application-wide timers.
> This action is erroneously disallowed based on Table 2 in the EJB3 specification, section 4.5.2 (IMHO).
> Service lifecycle methods are not dependency injection methods, furthermore @Service beans are outside of the EJB3 specification.
> Lifecycle methods of a service should probably be considered business methods, not DI in the context of Table 2. They are in the @Management business interface.
> There is no workaround yet for this backwards incompatible change which breaks apps that set up application-wide timers from Services when they are migrated to 5.0.0.GA. This used to work in 4.2.x.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Tue Jul 14 06:37:29 2009
From: jira-events at lists.jboss.org (francesco dicarlo (JIRA))
Date: Tue, 14 Jul 2009 06:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-306) Variable Instances
 translation
 funcionality(From MessageValue to simple types like String,Integer,Long)
In-Reply-To: <2123265903.1246520763456.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <73597139.1247567849283.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/BPEL-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476175#action_12476175 ] 

francesco dicarlo commented on BPEL-306:
----------------------------------------

yes it is. 

> Variable Instances translation funcionality(From MessageValue to simple types like String,Integer,Long)
> -------------------------------------------------------------------------------------------------------
>
>                 Key: BPEL-306
>                 URL: https://jira.jboss.org/jira/browse/BPEL-306
>             Project: JBoss jBPM BPEL
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1.1
>         Environment: Jboss 4.2.3.GA
> JBPM-BPEL 1.1.1
>            Reporter: francesco dicarlo
>            Assignee: Alejandro Guizar
>
> Would be good to have a functionality (i.e. a Translator) to automatically translate VariableInstance that in JBPM-BPEL are of type MessageValue into the simple type that were defined in the workflow.
> The use of this code \\Map varsMap=instance.getContextInstance().getVariables();\\ returns a Map with key the name of the variable but with value a type MessageValue that can't be translated automatically for all the workflow because relies on workflow implementation and design.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 07:44:29 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Tue, 14 Jul 2009 07:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
Message-ID: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

jboss messaging / memory leak on session.rollback() operation
-------------------------------------------------------------

                 Key: JBMESSAGING-1685
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.3.GA
         Environment: Windows Server 2003/SP2
            Reporter: Martin Gysel
            Assignee: Tim Fox
             Fix For: 1.4.3.GA


we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.

the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
- close session/connection after so many rollback() operation, e.g. 100
- close session/connection after all messages have been received (and removed)
- clustered vs. not clustered makes no difference
- hypersonic vs. db2 makes no difference
- adding a DLQ makes no difference
- DeliveryMode.NON_PERSISTENT makes no difference

the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
we do not use XA.

thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 07:46:30 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Jul 2009 07:46:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1616) Classpath
 issue with file version.properties
In-Reply-To: <7671035.1241530427144.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1322292433.1247571990034.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1616:
---------------------------------

    Fix Version/s: 2.0.0


> Classpath issue with file version.properties
> --------------------------------------------
>
>                 Key: JBMESSAGING-1616
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1616
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Alpha
>            Reporter: Markus Probst
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> In class org.jboss.messaging.util.VersionLoader the static method "load" throws a NumberFormatException while trying to read properties from file version.properties, if several files with this name are situated in current classpath and the "wrong" one is picked up:
> "
> java.lang.NumberFormatException: null
> at java.lang.Integer.parseInt(Integer.java:415)
> at java.lang.Integer.valueOf(Integer.java:553)
> at org.jboss.messaging.util.VersionLoader.load(VersionLoader.java:50)
> at org.jboss.messaging.core.client.impl.ClientConnectionFactoryImpl.createConnection(ClientConnectionFactoryImpl.java:135)
> at org.jboss.messaging.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:255)
> at org.jboss.messaging.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:134)
> ...
> "
> It is very likely that more than one library/artifacts contains a file called "version.properties", so I think the right way should be to rename this file to a more JBoss Messaging specific one.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 08:32:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Tue, 14 Jul 2009 08:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <2079693420.1247574749324.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476185#action_12476185 ] 

Ales Justin commented on JBAS-7032:
-----------------------------------

Stan, can you attach this "fixed" ear.
Or how do I reproduce this?

I'm looking into WBINT-16, which is what is mentioned at the end of WBINT-15 discussion.

Do we have any clue why admin-console uses that WBPhaseListener?
As WebBeansUrlIntegrationDeployer is pretty simple and shouldn't add faces/ to cp.

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 09:13:30 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Tue, 14 Jul 2009 09:13:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6185) JBoss MBeans in
 JConsole no longer works
In-Reply-To: <26907503.1226244456723.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1013727811.1247577210101.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch resolved JBAS-6185.
----------------------------------

    Resolution: Done


>From ScottM...

> a) just using the platform mbean server stills works (no jconsole)
>    

This works

> b) just using com.sun.remoting still works (jconsole, but no java mbean in the jmxconsole)
>    

This also works


> JBoss MBeans in JConsole no longer works 
> -----------------------------------------
>
>                 Key: JBAS-6185
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6185
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.0.0.CR2
>         Environment: JBossAS-5 CR2, Sun Java 1.5, Windows 2003
>            Reporter: jaikiran pai
>            Assignee: Scott Marlow
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Displaying of JBoss MBeans in JConsole as explained here http://www.jboss.org/community/docs/DOC-10521 , no longer works because of the classpath issue. Maybe related to the refactoring of org\jboss\system\server\jmx\* classes into jboss-system-jmx.jar in JBoss-5.
> More details about this issue can be found in the linked forum thread.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 09:15:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Tue, 14 Jul 2009 09:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBAS-7097) Stack overflow error
 when establishing secured connection to Profile Service
Message-ID: <1644879891.1247577329470.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukas Krejci moved JOPR-286 to JBAS-7097:
-----------------------------------------

        Project: JBoss Application Server  (was: Jopr)
            Key: JBAS-7097  (was: JOPR-286)
    Component/s: ProfileService
                     (was: Plugin - JBoss AS 5)


> Stack overflow error when establishing secured connection to Profile Service
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7097
>             Project: JBoss Application Server
>          Issue Type: Bug
>          Components: ProfileService
>         Environment: Jopr rev902, AS5 EAP rev91190
>            Reporter: Lukas Krejci
>            Priority: Blocker
>
> The stack overflow occurs in AbstractProfileServiceConnection.init() after the connection has been established.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
>         at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
> Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
>         at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
>         at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
>         ... 12 more                                                                                                                                                                       
> Caused by: java.lang.StackOverflowError                                                                                                                                                   
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
> ....                                                                           
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
>         ... 18 more                                                                                                                                                                       

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 09:17:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Jul 2009 09:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1628) lack of
 support for java 1.4 clients
In-Reply-To: <11536840.1242421546884.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1123361493.1247577449298.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476201#action_12476201 ] 

Tim Fox commented on JBMESSAGING-1628:
--------------------------------------

Sorry! No plans to support 1.4 clients. We just don't have enough interest in this to make it worthwhile. 

> lack of support for java 1.4 clients
> ------------------------------------
>
>                 Key: JBMESSAGING-1628
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1628
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Remoting
>    Affects Versions: 1.4.3.GA
>         Environment: windows xp, j2sdk1.4.2_13 and jdk1.6.0_05
>            Reporter: alexguev
>            Assignee: Tim Fox
>
> The messaging clients libraries are java 5 bytecode, which prevents the use of jboss messaging from java 1.4 code. I made an attempt to retro-translate the messaging client libraries using the retrotranslator project with limited success. Basically, things went pretty well up to the point where the java vm complained with this error:
> java.lang.ClassFormatError: org/jboss/jms/client/delegate/ClientConnectionFactoryDelegate (Invalid start_pc/length in local var table)
> I was wondering if there are any plans for jboss-messaging to support java 1.4 clients ? also, should I try using the jboss-retro project instead ?
> thanks in advance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 09:17:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Jul 2009 09:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1628) lack of
 support for java 1.4 clients
In-Reply-To: <11536840.1242421546884.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <113494244.1247577449416.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox closed JBMESSAGING-1628.
--------------------------------

    Resolution: Rejected


> lack of support for java 1.4 clients
> ------------------------------------
>
>                 Key: JBMESSAGING-1628
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1628
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Remoting
>    Affects Versions: 1.4.3.GA
>         Environment: windows xp, j2sdk1.4.2_13 and jdk1.6.0_05
>            Reporter: alexguev
>            Assignee: Tim Fox
>
> The messaging clients libraries are java 5 bytecode, which prevents the use of jboss messaging from java 1.4 code. I made an attempt to retro-translate the messaging client libraries using the retrotranslator project with limited success. Basically, things went pretty well up to the point where the java vm complained with this error:
> java.lang.ClassFormatError: org/jboss/jms/client/delegate/ClientConnectionFactoryDelegate (Invalid start_pc/length in local var table)
> I was wondering if there are any plans for jboss-messaging to support java 1.4 clients ? also, should I try using the jboss-retro project instead ?
> thanks in advance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 09:19:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Tue, 14 Jul 2009 09:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1621333158.1247577569212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox updated JBMESSAGING-1677:
---------------------------------

    Fix Version/s: 2.0.0


> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>         Attachments: JmsTest-v2.zip, JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 09:21:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Tue, 14 Jul 2009 09:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7097) Stack overflow
 error when establishing secured connection to Profile Service
Message-ID: <319874981.1247577689597.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476203#action_12476203 ] 

Lukas Krejci commented on JBAS-7097:
------------------------------------

This exception occurs during DeploymentManager.loadProfile() method wrapped in a dynamic proxy with http://anonsvn.jboss.org/repos/jopr/trunk/modules/plugins/jboss-as-5/src/main/java/org/rhq/plugins/jbossas5/connection/JaasAuthenticationInvocationHandler.java as a handler.

> Stack overflow error when establishing secured connection to Profile Service
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7097
>             Project: JBoss Application Server
>          Issue Type: Bug
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Jopr rev902, AS5 EAP rev91190
>            Reporter: Lukas Krejci
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The stack overflow occurs in AbstractProfileServiceConnection.init() after the connection has been established.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
>         at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
> Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
>         at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
>         at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
>         ... 12 more                                                                                                                                                                       
> Caused by: java.lang.StackOverflowError                                                                                                                                                   
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
> ....                                                                           
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
>         ... 18 more                                                                                                                                                                       

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 09:21:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Tue, 14 Jul 2009 09:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7097) Stack overflow
 error when establishing secured connection to Profile Service
Message-ID: <982882790.1247577689804.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukas Krejci reassigned JBAS-7097:
----------------------------------

    Assignee: Scott M Stark


> Stack overflow error when establishing secured connection to Profile Service
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7097
>             Project: JBoss Application Server
>          Issue Type: Bug
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Jopr rev902, AS5 EAP rev91190
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The stack overflow occurs in AbstractProfileServiceConnection.init() after the connection has been established.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
>         at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
> Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
>         at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
>         at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
>         ... 12 more                                                                                                                                                                       
> Caused by: java.lang.StackOverflowError                                                                                                                                                   
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
> ....                                                                           
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
>         ... 18 more                                                                                                                                                                       

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 09:21:30 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Tue, 14 Jul 2009 09:21:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7097) Stack overflow error
 when establishing secured connection to Profile Service
Message-ID: <1362091935.1247577690327.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7097:
-------------------------------

        Fix Version/s: JBossAS-5.2.0.Beta1
    Affects Version/s: JBossAS-5.1.0.GA
               Labels: EmbJopr1_3 profileservice  (was: )


> Stack overflow error when establishing secured connection to Profile Service
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7097
>             Project: JBoss Application Server
>          Issue Type: Bug
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Jopr rev902, AS5 EAP rev91190
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The stack overflow occurs in AbstractProfileServiceConnection.init() after the connection has been established.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
>         at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
> Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
>         at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
>         at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
>         ... 12 more                                                                                                                                                                       
> Caused by: java.lang.StackOverflowError                                                                                                                                                   
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
> ....                                                                           
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
>         ... 18 more                                                                                                                                                                       

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 09:27:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Tue, 14 Jul 2009 09:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7097) Stack overflow error
 when establishing secured connection to Profile Service
Message-ID: <471920220.1247578049317.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukas Krejci updated JBAS-7097:
-------------------------------

    Description: 
The stack overflow occurs in Jopr AS5 plugin AbstractProfileServiceConnection.init() after the connection has been established.

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
        at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
        at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
        at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
        at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
        at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
        at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
        at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
        at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
        at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
        at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
        at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
        at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
        at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
        ... 12 more                                                                                                                                                                       
Caused by: java.lang.StackOverflowError                                                                                                                                                   
        at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
        at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
        at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
        at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
        at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
        at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
        at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
....                                                                           
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
        at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
        at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
        at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
        at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
        ... 18 more                                                                                                                                                                       

  was:
The stack overflow occurs in AbstractProfileServiceConnection.init() after the connection has been established.

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
        at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
        at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
        at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
        at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
        at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
        at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
        at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
        at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
        at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
        at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
        at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
        at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
        at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
        ... 12 more                                                                                                                                                                       
Caused by: java.lang.StackOverflowError                                                                                                                                                   
        at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
        at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
        at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
        at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
        at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
        at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
        at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
....                                                                           
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
        at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
        at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
        at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
        at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
        at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
        ... 18 more                                                                                                                                                                       



> Stack overflow error when establishing secured connection to Profile Service
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7097
>             Project: JBoss Application Server
>          Issue Type: Bug
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Jopr rev902, AS5 EAP rev91190
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The stack overflow occurs in Jopr AS5 plugin AbstractProfileServiceConnection.init() after the connection has been established.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
>         at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
> Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
>         at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
>         at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
>         ... 12 more                                                                                                                                                                       
> Caused by: java.lang.StackOverflowError                                                                                                                                                   
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
> ....                                                                           
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
>         ... 18 more                                                                                                                                                                       

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 09:31:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Tue, 14 Jul 2009 09:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7076) DeploymentTemplate
 temp file url is not escaped properly
In-Reply-To: <1147631592.1246738311392.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1294125563.1247578289565.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7076:
---------------------------------

    Labels: profileservice  (was: )


> DeploymentTemplate temp file url is not escaped properly
> --------------------------------------------------------
>
>                 Key: JBAS-7076
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7076
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>
> The DsDataSourceTemplate applyTemplate method is creating a temp file, but somewhere the file url is not being properly escaped (at least on mac os x), as a temp file name of
> /var/folders/jY/jY1BDqLkHKO+a4nm+GooZE+++TI/-Tmp-/DsDataSourceTemplate9162352335796065232-ds.xml
> is created, but when the file is accessed by the vfs, it fails with:
> java.io.FileNotFoundException: /var/folders/jY/jY1BDqLkHKO a4nm GooZE   TI/-Tmp-/DsDataSourceTemplate9162352335796065232-ds.xml

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 09:31:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Tue, 14 Jul 2009 09:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7085) Replace ejb3 secured
 profile service facade with secured remoting proxy
In-Reply-To: <1810173299.1247085411421.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1272390950.1247578289491.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7085:
---------------------------------

    Priority: Critical  (was: Major)


> Replace ejb3 secured profile service facade with secured remoting proxy
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7085
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7085
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService, Security
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Its been decided to limit the number of dependencies an admin client needs to communicate with a secured profile service. We need to drop the ejb3 facade and provide a secured remoting based proxy bound in global jndi and an unsecured, but security manager controlled unsecured proxy under the java: local jndi namespace.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 09:33:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Tue, 14 Jul 2009 09:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7074) some jars required
 by remote Profile Service clients are not included in client/ or
 client/jbossall-client.jar's Manifest classpath
In-Reply-To: <631441563.1246562451433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1399819725.1247578409183.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7074:
---------------------------------

    Labels: profileservice  (was: )


> some jars required by remote Profile Service clients are not included in client/ or client/jbossall-client.jar's Manifest classpath
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7074
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7074
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The following jar is missing from client/jbossall-client.jar's Manifest classpath and from client/:
>    common/lib/jboss-security-aspects.jar
> Its corresponding Maven artifact is org.jboss.aspects:jboss-security-aspects.
> If I find any others, I will update this JIRA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 09:37:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Tue, 14 Jul 2009 09:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7097) Stack overflow
 error when establishing secured connection to Profile Service
Message-ID: <740224745.1247578649409.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476207#action_12476207 ] 

Charles Crouch commented on JBAS-7097:
--------------------------------------

(8:23:33 AM) ips: stackoverflowerror in the new aop security code...
(8:32:50 AM) ccrouch: "new" as in from JBAS-7085 or new from JOPR-263 ?
(8:33:17 AM) ips: 7085 i think
(8:33:56 AM) ips: 263 was working great on my box - tested pretty thoroughly
(8:34:23 AM) ips: lukas saw this for the first time this morning after updating his EAP build to the latest 

> Stack overflow error when establishing secured connection to Profile Service
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7097
>             Project: JBoss Application Server
>          Issue Type: Bug
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Jopr rev902, AS5 EAP rev91190
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The stack overflow occurs in Jopr AS5 plugin AbstractProfileServiceConnection.init() after the connection has been established.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
>         at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
> Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
>         at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
>         at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
>         ... 12 more                                                                                                                                                                       
> Caused by: java.lang.StackOverflowError                                                                                                                                                   
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
> ....                                                                           
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
>         ... 18 more                                                                                                                                                                       

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 10:02:42 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 14 Jul 2009 10:02:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <64958667.1247580162076.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert updated JBAS-7032:
-------------------------------

    Attachment: WhatUpDawg.ear


Corrected version with jars in WEB-INF/lib instead of ear root

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 10:08:30 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 14 Jul 2009 10:08:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <1734300986.1247580510070.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476221#action_12476221 ] 

Stan Silvert commented on JBAS-7032:
------------------------------------

You can reproduce this by dropping the new ear into /deploy on jboss-5.1.0.GA.

The reason admin-console is using WBPhaseListener is because it is there.  When admin-console starts up, JSF sees the path /webbeans.deployer/lib-int/faces on its classpath.  JSF searches its classpath for META-INF/faces-config.xml files.  When it see the faces-config.xml for webbeans it installs the WBPhaseListener.

So I think the problem is that the WB deployer is putting itself on the classpath in such a way that the admin-console sees it.  admin-console shoudn't know anything about the /webbeans.deployer/lib-int/faces directory.

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 10:12:29 2009
From: jira-events at lists.jboss.org (Michal Rorat (JIRA))
Date: Tue, 14 Jul 2009 10:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7092) Server fails to
 deploy war files in ear.
In-Reply-To: <775540505.1247229042120.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2121990198.1247580749527.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476226#action_12476226 ] 

Michal Rorat commented on JBAS-7092:
------------------------------------

I was able to drill down this issue to one of JBoss classes. I was debugging even deeper but without success...

org.jboss.web.AbstractWebDeployer:500

<code>
         envCtx.bind("UserTransaction", new LinkRef("UserTransaction"));
</code>

JBoss is binding UserTransaction, but for some reason for any module which is deployed as 34th this name is already registered in NamingServer - like I said before - even when the module is an empty jar or war.

For now we are using workaround (really nasty one) where we are deleting everything from NamingServer each time we are deploying module. So the code loks like that:

org.jboss.web.AbstractWebDeployer:500

<code>
         ((NamingServer)((NamingContext)envCtx).getNaming()).deleteAllBindings();
         envCtx.bind("UserTransaction", new LinkRef("UserTransaction"));
</code>

and org.jnp.server.NamingServer change:

<code>
   public void deleteAllBindings()
   {
	   table = new Hashtable();
   }
</code>

Maybe this will help to resolve the issue.

Regards,
Michal Rorat

> Server fails to deploy war files in ear.
> ----------------------------------------
>
>                 Key: JBAS-7092
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7092
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-4.2.3.GA
>         Environment: Windows XP 32 bit
> Windows 2003 Server
>            Reporter: Michal Rorat
>            Assignee: Ales Justin
>
> I have an ear file which contains ejbs and wars. It started to fail when I added sars. The problem is, it doesn't matter what wars I'm deploying, its always the second one and nothing gets deployed after this exception.
> aplication.xml file:
> <?xml version="1.0" encoding="UTF-8"?>
> <application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:application="http://java.sun.com/xml/ns/javaee/application_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd" id="Application_ID" version="5">
>   <module>
>     <java>OracleQueue.sar</java>
>   </module>
>   <module>
>     <java>SONController.sar</java>
>   </module>
>   <module>
>     <ejb>Admin.jar</ejb>
>   </module>
>   <module>
>     <ejb>Settings.jar</ejb>
>   </module>
>   <module>
>     <ejb>Layer3Msg.jar</ejb>
>   </module>
>   <module>
>     <java>Layer3MsgLoader.sar</java>
>   </module>
>   <module>
>     <ejb>Layer3MsgMdb.jar</ejb>
>   </module>
>   <module>
>     <ejb>Common.jar</ejb>
>   </module>
>   <module>
>     <ejb>Attributes.jar</ejb>
>   </module>
>   <module>
>     <ejb>Data.jar</ejb>
>   </module>
>   <module>
>     <ejb>Model.jar</ejb>
>   </module>
>   <module>
>     <ejb>Users.jar</ejb>
>   </module>
>   <module>
>     <ejb>Tasks.jar</ejb>
>   </module>
>   <module>
>     <ejb>Survey.jar</ejb>
>   </module>
>   <module>
>     <ejb>BenchmarkQpis.jar</ejb>
>   </module>
>   <module>
>     <ejb>Cellrefutils.jar</ejb>
>   </module>
>   <module>
>     <ejb>ConfigChanges.jar</ejb>
>   </module>
>   <module>
>     <ejb>Engine.jar</ejb>
>   </module>
>   <module>
>     <ejb>Events.jar</ejb>
>   </module>
>   <module>
>     <ejb>QueryDefs.jar</ejb>
>   </module>
>   <module>
>     <ejb>QueryData.jar</ejb>
>   </module>
>   <module>
>     <ejb>GeoTagging.jar</ejb>
>   </module>
>   <module>
>     <ejb>Kpievents.jar</ejb>
>   </module>
>   <module>
>     <ejb>Modules.jar</ejb>
>   </module>
>   <module>
>     <ejb>Network.jar</ejb>
>   </module>
>   <module>
>     <ejb>Qpis.jar</ejb>
>   </module>
>   <module>
>     <ejb>RadioNetworkAnalysis.jar</ejb>
>   </module>
>   <module>
>     <ejb>VirtualEarth.jar</ejb>
>   </module>
>   <module>
>     <ejb>WMS.jar</ejb>
>   </module>
>   <module>
>     <ejb>ReportData.jar</ejb>
>   </module>
>   <module>
>     <ejb>ReportsMetadata.jar</ejb>
>   </module>
>   <module>
>     <ejb>ReportProducer.jar</ejb>
>   </module>
>   <module>
>     <web>
>       <web-uri>Quorre.war</web-uri>
>       <context-root>ActixOne/Quorre</context-root>
>     </web>
>   </module>
>   <module>
>     <web>
>       <web-uri>TestWar.war</web-uri>
>       <context-root>TestWar</context-root>
>     </web>
>   </module>
>   <module>
>     <web>
>       <web-uri>Download.war</web-uri>
>       <context-root>ActixOne/Download</context-root>
>     </web>
>   </module>
> </application>
> Exception:
> 2009-07-10 12:28:30,687 INFO  [org.jboss.ejb3.EJB3Deployer] Deployed: file:/C:/jboss-4.2/server/default/tmp/deploy/tmp4660403835223254272ActixOne.ear-contents/ReportProducer.jar
> 2009-07-10 12:28:30,687 INFO  [org.jboss.web.tomcat.service.TomcatDeployer] deploy, ctxPath=/ActixOne/Quorre, warUrl=.../tmp/deploy/tmp4660403835223254272ActixOne.ear-contents/Quorre-exp.war/
> 2009-07-10 12:28:30,875 INFO  [org.rhq.helpers.rtfilter.filter.RtFilter] Initialized response-time filter for webapp with context root 'ActixOne/Quorre'.
> 2009-07-10 12:28:31,687 INFO  [org.jboss.web.tomcat.service.TomcatDeployer] deploy, ctxPath=/TestWar, warUrl=.../tmp/deploy/tmp4660403835223254272ActixOne.ear-contents/TestWar-exp.war/
> 2009-07-10 12:28:31,687 WARN  [org.jboss.system.ServiceController] Problem starting service jboss.web.deployment:war=TestWar.war,id=2043149425
> org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)
> 	at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:384)
> 	at org.jboss.web.WebModule.startModule(WebModule.java:83)
> 	at org.jboss.web.WebModule.startService(WebModule.java:61)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> 	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> 	at $Proxy0.start(Unknown Source)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:417)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.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 $Proxy45.start(Unknown Source)
> 	at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:466)
> 	at sun.reflect.GeneratedMethodAccessor85.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
> 	at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
> 	at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:87)
> 	at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
> 	at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
> 	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 $Proxy46.start(Unknown Source)
> 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
> 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> 	at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.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(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> 	at $Proxy0.start(Unknown Source)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:417)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.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:304)
> 	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(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.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(Unknown Source)
> Caused by: javax.naming.NameAlreadyBoundException
> 	at org.jnp.server.NamingServer.bind(NamingServer.java:144)
> 	at org.jnp.interfaces.NamingContext.bind(NamingContext.java:591)
> 	at org.jnp.interfaces.NamingContext.bind(NamingContext.java:552)
> 	at org.jboss.web.AbstractWebDeployer.parseWebAppDescriptors(AbstractWebDeployer.java:495)
> 	at org.jboss.web.AbstractWebDeployer$DescriptorParser.parseWebAppDescriptors(AbstractWebDeployer.java:878)
> 	at org.jboss.web.tomcat.service.TomcatDeployer.performDeployInternal(TomcatDeployer.java:159)
> 	at org.jboss.web.tomcat.service.TomcatDeployer.performDeploy(TomcatDeployer.java:104)
> 	at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:375)
> 	... 112 more
> 2009-07-10 12:28:31,718 ERROR [org.jboss.deployment.MainDeployer] Could not start deployment: file:/C:/jboss-4.2/server/default/tmp/deploy/tmp4660403835223254272ActixOne.ear-contents/TestWar.war
> org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)
> 	at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:384)
> 	at org.jboss.web.WebModule.startModule(WebModule.java:83)
> 	at org.jboss.web.WebModule.startService(WebModule.java:61)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> 	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> 	at $Proxy0.start(Unknown Source)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:417)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.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 $Proxy45.start(Unknown Source)
> 	at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:466)
> 	at sun.reflect.GeneratedMethodAccessor85.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
> 	at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
> 	at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:87)
> 	at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
> 	at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
> 	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 $Proxy46.start(Unknown Source)
> 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
> 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> 	at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.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(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> 	at $Proxy0.start(Unknown Source)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:417)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.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:304)
> 	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(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.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(Unknown Source)
> Caused by: javax.naming.NameAlreadyBoundException
> 	at org.jnp.server.NamingServer.bind(NamingServer.java:144)
> 	at org.jnp.interfaces.NamingContext.bind(NamingContext.java:591)
> 	at org.jnp.interfaces.NamingContext.bind(NamingContext.java:552)
> 	at org.jboss.web.AbstractWebDeployer.parseWebAppDescriptors(AbstractWebDeployer.java:495)
> 	at org.jboss.web.AbstractWebDeployer$DescriptorParser.parseWebAppDescriptors(AbstractWebDeployer.java:878)
> 	at org.jboss.web.tomcat.service.TomcatDeployer.performDeployInternal(TomcatDeployer.java:159)
> 	at org.jboss.web.tomcat.service.TomcatDeployer.performDeploy(TomcatDeployer.java:104)
> 	at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:375)
> 	... 112 more
> 2009-07-10 12:28:31,718 ERROR [org.jboss.deployment.scanner.URLDeploymentScanner] Incomplete Deployment listing:
> --- Incompletely deployed packages ---
> org.jboss.deployment.DeploymentInfo at 11dba24c { url=file:/C:/jboss-4.2/server/default/deploy/ActixOne.ear }
>   deployer: org.jboss.deployment.EARDeployer at 7981d5
>   status: Deployment FAILED reason: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)
>   state: FAILED
>   watch: file:/C:/jboss-4.2/server/default/deploy/ActixOne.ear
>   altDD: null
>   lastDeployed: 1247225246750
>   lastModified: 1247225222906
>   mbeans:
>     jboss.j2ee:ear=ActixOne.ear,jar=Admin.jar,name=Admin,service=EJB3 state: Started
>     persistence.units:ear=ActixOne.ear,jar=Settings.jar,unitName=SettingsStorage state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Settings.jar,name=Settings,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Layer3Msg.jar,name=Layer3Msg,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Layer3MsgMdb.jar,name=ReportProducerMDB,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Common.jar,name=Common,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Attributes.jar,name=Attributes,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Data.jar,name=Data,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Model.jar,name=Model,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Users.jar,name=Users,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Tasks.jar,name=Tasks,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Survey.jar,name=Survey,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=BenchmarkQpis.jar,name=Benchmarkqpis,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Cellrefutils.jar,name=Cellrefutils,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=ConfigChanges.jar,name=Configchanges,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Engine.jar,name=Engine,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Events.jar,name=Events,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=QueryDefs.jar,name=QueryDefs,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=QueryData.jar,name=QueryData,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=GeoTagging.jar,name=Geotagging,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Kpievents.jar,name=Kpievents,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Modules.jar,name=Modules,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Network.jar,name=Network,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=Qpis.jar,name=Qpis,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=RadioNetworkAnalysis.jar,name=RadioNetworkAnalysis,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=VirtualEarth.jar,name=VirtualEarth,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=WMS.jar,name=Wms,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=ReportData.jar,name=ReportData,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=ReportsMetadata.jar,name=ReportsMetadata,service=EJB3 state: Started
>     jboss.j2ee:ear=ActixOne.ear,jar=ReportProducer.jar,name=ReportProducerMDB,service=EJB3 state: Started
> --- MBeans waiting for other MBeans ---
> ObjectName: jboss:service=KeyGeneratorFactory,type=HiLo
>   State: CONFIGURED
>   I Depend On:
>     jboss:service=TransactionManager
>     jboss.jca:service=DataSourceBinding,name=DefaultDS
> ObjectName: jboss.cache:service=InvalidationBridge,type=JavaGroups
>   State: CONFIGURED
>   I Depend On:
>     jboss:service=DefaultPartition
>     jboss.cache:service=InvalidationManager
> ObjectName: jboss.mq:service=InvocationLayer,type=HTTP
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=Invoker
>     jboss.web:service=WebServer
> ObjectName: jboss.mq:service=StateManager
>   State: CONFIGURED
>   I Depend On:
>     jboss.jca:service=DataSourceBinding,name=DefaultDS
>   Depends On Me:
>     jboss.mq:service=DestinationManager
> ObjectName: jboss.mq:service=DestinationManager
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=MessageCache
>     jboss.mq:service=PersistenceManager
>     jboss.mq:service=StateManager
>     jboss.mq:service=ThreadPool
>     jboss:service=Naming
>   Depends On Me:
>     jboss.mq.destination:service=Topic,name=testTopic
>     jboss.mq.destination:service=Topic,name=securedTopic
>     jboss.mq.destination:service=Topic,name=testDurableTopic
>     jboss.mq.destination:service=Queue,name=testQueue
>     jboss.mq.destination:service=Queue,name=A
>     jboss.mq.destination:service=Queue,name=B
>     jboss.mq.destination:service=Queue,name=C
>     jboss.mq.destination:service=Queue,name=D
>     jboss.mq.destination:service=Queue,name=ex
>     jboss.mq:service=SecurityManager
>     jboss.mq.destination:service=Queue,name=DLQ
> ObjectName: jboss.mq:service=PersistenceManager
>   State: CONFIGURED
>   I Depend On:
>     jboss.jca:service=DataSourceBinding,name=DefaultDS
>   Depends On Me:
>     jboss.mq:service=DestinationManager
> ObjectName: jboss.mq.destination:service=Topic,name=testTopic
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
>     jboss.mq:service=SecurityManager
> ObjectName: jboss.mq.destination:service=Topic,name=securedTopic
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
>     jboss.mq:service=SecurityManager
> ObjectName: jboss.mq.destination:service=Topic,name=testDurableTopic
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
>     jboss.mq:service=SecurityManager
> ObjectName: jboss.mq.destination:service=Queue,name=testQueue
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
>     jboss.mq:service=SecurityManager
> ObjectName: jboss.mq.destination:service=Queue,name=A
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
> ObjectName: jboss.mq.destination:service=Queue,name=B
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
> ObjectName: jboss.mq.destination:service=Queue,name=C
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
> ObjectName: jboss.mq.destination:service=Queue,name=D
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
> ObjectName: jboss.mq.destination:service=Queue,name=ex
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
> ObjectName: jboss.mq:service=Invoker
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=TracingInterceptor
>     jboss:service=Naming
>   Depends On Me:
>     jboss.mq:service=InvocationLayer,type=HTTP
>     jboss.mq:service=InvocationLayer,type=JVM
>     jboss.mq:service=InvocationLayer,type=UIL2
> ObjectName: jboss.mq:service=TracingInterceptor
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=SecurityManager
>   Depends On Me:
>     jboss.mq:service=Invoker
> ObjectName: jboss.mq:service=SecurityManager
>   State: CONFIGURED
>   I Depend On:
>     jboss.security:service=JaasSecurityManager
>     jboss.mq:service=DestinationManager
>   Depends On Me:
>     jboss.mq.destination:service=Topic,name=testTopic
>     jboss.mq.destination:service=Topic,name=securedTopic
>     jboss.mq.destination:service=Topic,name=testDurableTopic
>     jboss.mq.destination:service=Queue,name=testQueue
>     jboss.mq:service=TracingInterceptor
>     jboss.mq.destination:service=Queue,name=DLQ
> ObjectName: jboss.mq.destination:service=Queue,name=DLQ
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=DestinationManager
>     jboss.mq:service=SecurityManager
> ObjectName: jboss.mq:service=InvocationLayer,type=JVM
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=Invoker
> ObjectName: jboss.mq:service=InvocationLayer,type=UIL2
>   State: CONFIGURED
>   I Depend On:
>     jboss.mq:service=Invoker
> ObjectName: jboss.web.deployment:war=TestWar.war,id=2043149425
>   State: FAILED
>   Reason: org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)
> --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
> ObjectName: jboss.web.deployment:war=TestWar.war,id=2043149425
>   State: FAILED
>   Reason: org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (javax.naming.NameAlreadyBoundException)
> ObjectName: jboss.cache:service=InvalidationManager
>   State: NOTYETINSTALLED
>   Depends On Me:
>     jboss.cache:service=InvalidationBridge,type=JavaGroups
> ObjectName: jboss.jca:service=DataSourceBinding,name=DefaultDS
>   State: NOTYETINSTALLED
>   Depends On Me:
>     jboss:service=KeyGeneratorFactory,type=HiLo
>     jboss.mq:service=StateManager
>     jboss.mq:service=PersistenceManager
> *********************************************************************
> I found out that I'm not the only one with problem like that:
> http://www.techienuggets.com/Detail?tx=27457
> Regards,
> Michal Rorat

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 10:16:29 2009
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Tue, 14 Jul 2009 10:16:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2431) SQLException on
 user login if hibernate schema name is specified
Message-ID: <1066866667.1247580989444.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SQLException on user login if hibernate schema name is specified
----------------------------------------------------------------

                 Key: JBPORTAL-2431
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2431
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal CMS
    Affects Versions: 2.7.2 Final
         Environment: JBoss Portal set up with a dedicated schema name (eg. on Oracle), <property name="hibernate.default_schema">epp43</property> added to all hibernate config files:

deploy/jboss-portal.sar/portal-cms.sar/conf/hibernate/cms/hibernate.cfg.xml
deploy/jboss-portal.sar/conf/hibernate/portal/hibernate.cfg.xml
deploy/jboss-portal.sar/conf/hibernate/portlet/hibernate.cfg.xml
deploy/jboss-portal.sar/conf/hibernate/workflow/hibernate.cfg.xml
deploy/jboss-portal.sar/conf/hibernate/user/hibernate.cfg.xml
deploy/jboss-portal.sar/conf/hibernate/instance/hibernate.cfg.xml
deploy/jboss-portal.sar/portal-wsrp.sar/conf/hibernate/consumer/hibernate.cfg.xml

            Reporter: Martin Putz
            Assignee: Sohil Shah


2009-07-13 12:24:30,751 DEBUG [org.hibernate.SQL] SELECT p.* 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=?
2009-07-13 12:24:30,751 DEBUG [org.hibernate.type.StringType] binding 'ora2' to parameter: 1
2009-07-13 12:24:30,762 WARN  [org.hibernate.util.JDBCExceptionReporter] SQL Error: 942, SQLState: 42000
2009-07-13 12:24:30,763 ERROR [org.hibernate.util.JDBCExceptionReporter] ORA-00942: table or view does not exist

2009-07-13 12:24:30,763 ERROR [org.jboss.portal.cms.security.AuthorizationProviderImpl] org.jboss.portal.cms.security.AuthorizationProviderImpl at 12f1015
org.hibernate.exception.SQLGrammarException: could not execute query
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:67)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.loader.Loader.doList(Loader.java:2223)
at org.hibernate.loader.Loader.listUsingQueryCache(Loader.java:2136)
at org.hibernate.loader.Loader.list(Loader.java:2096)
at org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:289)
at org.hibernate.impl.SessionImpl.listCustomQuery(SessionImpl.java:1695)
at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:142)
at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:152)
at org.jboss.portal.cms.security.AuthorizationProviderImpl.findPermissionsByUser(AuthorizationProviderImpl.java:454)
...
Caused by: java.sql.SQLException: ORA-00942: table or view does not exist



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 10:41:29 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Tue, 14 Jul 2009 10:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2048793468.1247582489270.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------

    Description: 
we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.

the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
- close session/connection after this many rollback() operations, e.g. 100
- close session/connection after all messages have been received (and removed)
- clustered vs. not clustered makes no difference
- hypersonic vs. db2 makes no difference
- adding a DLQ makes no difference
- DeliveryMode.NON_PERSISTENT makes no difference

the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
session.commit() operations (x thousands and more) do not lead to a leak
we do not use XA.

thanks for your help.

  was:
we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.

the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
- close session/connection after so many rollback() operation, e.g. 100
- close session/connection after all messages have been received (and removed)
- clustered vs. not clustered makes no difference
- hypersonic vs. db2 makes no difference
- adding a DLQ makes no difference
- DeliveryMode.NON_PERSISTENT makes no difference

the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
we do not use XA.

thanks for your help.



> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Tim Fox
>             Fix For: 1.4.3.GA
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 11:12:30 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Tue, 14 Jul 2009 11:12:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <1673450328.1247584350013.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476247#action_12476247 ] 

Ales Justin commented on JBAS-7032:
-----------------------------------

>> So I think the problem is that the WB deployer is putting itself on the classpath in such a way that the admin-console sees it.

Can you check/debug why this is so?

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 11:42:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 14 Jul 2009 11:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2207) Session entry
 points cache is not being update on dynamic additions
Message-ID: <520287620.1247586149328.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Session entry points cache is not being update on dynamic additions
-------------------------------------------------------------------

                 Key: JBRULES-2207
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2207
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler, drools-core
    Affects Versions: 5.0.1.FINAL, 5.0.0.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1


package org.jboss.test.sam.drools;

import org.jboss.test.sam.drools.StockTick;

# default dialect
dialect "mvel"

# flag as event
declare StockTick
    @role( event )
end

# simple rule
rule "stream input test"
when
   $st: StockTick() from entry-point "in-channel"
then
   System.out.println("->"+$st);
end



java.lang.NullPointerException
        at org.drools.reteoo.EntryPointNode.updateSink(EntryPointNode.java:285)
        at org.drools.reteoo.ObjectTypeNode.attach(ObjectTypeNode.java:279)
        at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:160)
        at org.drools.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:289)
        at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:117)
        at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:70)
        at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:126)
        at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:73)
        at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:153)
        at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:126)
        at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
        at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:362)
        at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:618)
        at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:500)
        at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:379)
        at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:121)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 11:44:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 14 Jul 2009 11:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2207) Session entry
 points cache is not being update on dynamic additions
In-Reply-To: <520287620.1247586149328.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1295053659.1247586269160.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2207.
----------------------------------

    Resolution: Done


Fixed.

> Session entry points cache is not being update on dynamic additions
> -------------------------------------------------------------------
>
>                 Key: JBRULES-2207
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2207
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler, drools-core
>    Affects Versions: 5.0.0.FINAL, 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> package org.jboss.test.sam.drools;
> import org.jboss.test.sam.drools.StockTick;
> # default dialect
> dialect "mvel"
> # flag as event
> declare StockTick
>     @role( event )
> end
> # simple rule
> rule "stream input test"
> when
>    $st: StockTick() from entry-point "in-channel"
> then
>    System.out.println("->"+$st);
> end
> java.lang.NullPointerException
>         at org.drools.reteoo.EntryPointNode.updateSink(EntryPointNode.java:285)
>         at org.drools.reteoo.ObjectTypeNode.attach(ObjectTypeNode.java:279)
>         at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:160)
>         at org.drools.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:289)
>         at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:117)
>         at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:70)
>         at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:126)
>         at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:73)
>         at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:153)
>         at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:126)
>         at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117)
>         at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:362)
>         at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:618)
>         at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:500)
>         at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:379)
>         at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:121)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 12:11:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Jul 2009 12:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7048) Switch HAPartition to
 LongRunningTasksThreadPool
In-Reply-To: <20000345.1245771776621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <320366201.1247587889212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7048.
----------------------------------

    Resolution: Done


> Switch HAPartition to LongRunningTasksThreadPool
> ------------------------------------------------
>
>                 Key: JBAS-7048
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7048
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Now uses "ThreadPool" but for a long running task.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 12:13:29 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 14 Jul 2009 12:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-217)
 SchemaBindingValidator: extended XSD choice is not recognized
Message-ID: <694723892.1247588009184.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SchemaBindingValidator: extended XSD choice is not recognized
-------------------------------------------------------------

                 Key: JBXB-217
                 URL: https://jira.jboss.org/jira/browse/JBXB-217
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.2.Beta1
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: JBossXB-2.0.2.GA


Xerces XSD model for something like

   <xsd:complexType name="classloaderType" mixed="true">
      <xsd:complexContent>
         <xsd:extension base="classLoaderValueType"/>
      </xsd:complexContent>
   </xsd:complexType>

where classLoaderValueType is a choice will be represented by xerces as

sequence[choice[classLoaderValueType's choice content], sequence[]]

One of the confusing parts is the empty sequence at the end. Validator should be able to recognize a structure like this and treat it as a choice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 12:17:29 2009
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 14 Jul 2009 12:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-217)
 SchemaBindingValidator: extended XSD choice is not recognized
In-Reply-To: <694723892.1247588009184.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <621685161.1247588249501.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed JBXB-217.
----------------------------------

    Resolution: Done


Fixed.

> SchemaBindingValidator: extended XSD choice is not recognized
> -------------------------------------------------------------
>
>                 Key: JBXB-217
>                 URL: https://jira.jboss.org/jira/browse/JBXB-217
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.2.Beta1
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: JBossXB-2.0.2.GA
>
>
> Xerces XSD model for something like
>    <xsd:complexType name="classloaderType" mixed="true">
>       <xsd:complexContent>
>          <xsd:extension base="classLoaderValueType"/>
>       </xsd:complexContent>
>    </xsd:complexType>
> where classLoaderValueType is a choice will be represented by xerces as
> sequence[choice[classLoaderValueType's choice content], sequence[]]
> One of the confusing parts is the empty sequence at the end. Validator should be able to recognize a structure like this and treat it as a choice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 12:38:29 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Tue, 14 Jul 2009 12:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7085) Replace ejb3
 secured profile service facade with secured remoting proxy
In-Reply-To: <1810173299.1247085411421.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <909912127.1247589509681.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476261#action_12476261 ] 

Scott M Stark commented on JBAS-7085:
-------------------------------------

1) The jndi binding names are set by the following 3 jndiName properties of the ProfileServiceProxyFactory:

    <bean name="ProfileServiceProxyFactory" class="org.jboss.profileservice.remoting.ProxyFactory">
...
        <property name="jndiName">ProfileService</property>
        <property name="mgtViewJndiName">ManagementView</property>
        <property name="deployMgrJndiName">DeploymentManager</property>

2) the local unsecured ProfileService is only available via injection from the "ProfileService" MC bean. The unsecured ManagementView and DeploymentManager are available from that bean.

Authentication is enabled by default. To disable it the serverProxyInterceptors property of the ProfileServiceProxyFactory bean would have to be removed/set to an empty list vs the following default:

        <!-- Server side security interceptor stack -->
        <property name="serverProxyInterceptors">
            <list>
                <bean class="org.jboss.aspects.security.AuthenticationInterceptor">
                    <constructor>
                        <parameter>
                            <!-- AuthenticationManager -->
                            <value-factory bean="JNDIBasedSecurityManagement" method="getAuthenticationManager"
                            parameter="jmx-console"/>
                        </parameter>
                    </constructor>
                </bean>
                <bean class="org.jboss.aspects.security.RoleBasedAuthorizationInterceptor">
                    <constructor>
                        <!-- AuthenticationManager -->
                        <parameter>
                            <value-factory bean="JNDIBasedSecurityManagement" method="getAuthenticationManager"
                                parameter="jmx-console"/>
                        </parameter>
                        <!-- RealmMapping, the AuthenticationManager impl currently supports this -->
                        <parameter>
                            <value-factory bean="JNDIBasedSecurityManagement" method="getAuthenticationManager"
                                parameter="jmx-console"/>
                        </parameter>
                    </constructor>
                </bean>
            </list>
        </property>

> Replace ejb3 secured profile service facade with secured remoting proxy
> -----------------------------------------------------------------------
>
>                 Key: JBAS-7085
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7085
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService, Security
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Its been decided to limit the number of dependencies an admin client needs to communicate with a secured profile service. We need to drop the ejb3 facade and provide a secured remoting based proxy bound in global jndi and an unsecured, but security manager controlled unsecured proxy under the java: local jndi namespace.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 13:26:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Jul 2009 13:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7054) Allow configuring of
 Manager for distributable webapps via context.xml
In-Reply-To: <9414961.1245871139577.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2011859054.1247592389172.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7054.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


Note that the commits for this on trunk can be found under JBAS-7095; I inadvertently didn't use a separate commit.

> Allow configuring of Manager for distributable webapps via context.xml
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7054
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7054
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Tomcat) service
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> TomcatDeployment will currently always replace the session Manager impl for contexts it creates if the distributable flag is set in web.xml.  Add a flag to TomcatDeployer disable this behavior. This will allow use of a Manager configured via context.xml.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 13:28:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Jul 2009 13:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7091) Incorrect handling of
 timestamps in clustered session
In-Reply-To: <2099065379.1247195609545.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1854941497.1247592509156.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7091.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> Incorrect handling of timestamps in clustered session
> -----------------------------------------------------
>
>                 Key: JBAS-7091
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7091
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Tomcat) service
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> ClusteredSession has an "outdatedTime" field that records the timestamp when a session gets a callback notifying of a modification on another node.  If the session state later gets updated from the distributed cache, the clearOutdated() method ends up setting the session timestamp to that "outdatedTime" rather than the correct timestamp that's stored in the distributed cache. That's wrong.
> Not a big deal, as the difference between the outdatedTime and the correct timestamp is probably just a few ms (time it takes to replicate the session). But still, it's wrong.
> In any case the handling of "outdatedTime" is more complex than need and related "outdatedVersion" field can be removed altogether.  There's a bit of cruft here from the old days when correct timestamps weren't readily available from the cache.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 13:36:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Jul 2009 13:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7095) HA Web Sessions
 via Database Persistence
In-Reply-To: <1302881808.1247516429179.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1808038017.1247592989155.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476269#action_12476269 ] 

Brian Stansberry commented on JBAS-7095:
----------------------------------------

Code for this is currently in Branch_5_x, JBPAPP_5_0 and trunk. JIRA remains open pending some ongoing evaluation in the community.

> HA Web Sessions via Database Persistence
> ----------------------------------------
>
>                 Key: JBAS-7095
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7095
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Tomcat) service
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Occasionally we receive input from the JBoss AS user community that they'd like to see an option to use database persistence as a mechanism to make web sessions highly available. The basic use case we here for this is environments where sessions need to be available to AS instances located across a WAN. JBoss Cache/JGroups clusters can span a WAN but often users find it impractical to configure their cluster(s) in that way. However, their IT infrastructure already supports making RDBMS data accessible across the WAN. So, persisting sessions to the DB makes them available across the WAN.
> This JIRA is to create a session Manager impl that satisfies this request. It will be based on the distributed session manager code that we use with JBoss Cache replication, but the implementation of the DistributedCacheManager SPI that manager uses will be replaced with a version the interacts with a RDMBS.
> See http://www.jboss.org/community/wiki/HAWebSessionsviaDatabasePersistence for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 13:41:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 14 Jul 2009 13:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <56079735.1247593289362.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert updated JBAS-7032:
-------------------------------

    Attachment: PrintResourcePathContextListener.class


> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: PrintResourcePathContextListener.class, PrintResourcePathContextListener.java, WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 13:39:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 14 Jul 2009 13:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <907668522.1247593169416.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476270#action_12476270 ] 

Stan Silvert commented on JBAS-7032:
------------------------------------

I have verified that the analysis was correct.  I created a ServletContextListener (attached) that finds faces-config.xml files in the same manner as JSF.  When WhatsUpDawg.ear is deployed, admin-console finds the faces-config.xml file in /webbeans.deployer/lib-int/faces/META-INF/faces-config.xml.  Here is the output:

13:29:12,581 INFO  [STDOUT] ******************************************
13:29:12,583 INFO  [STDOUT] ** Resource Paths for META-INF/faces-config.xml:
13:29:12,602 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/org.jboss.seam-jboss-seam-2.1.0.SP1.jar/META-INF/faces-config.xml
13:29:12,607 INFO  [STDOUT] vfsfile:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deployers/webbeans.deployer/lib-int/faces/META-INF/faces-config.xml
13:29:12,610 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/jsf-facelets-1.1.15.B1.jar/META-INF/faces-config.xml
13:29:12,614 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/jboss-seam-debug-2.1.0.SP1.jar/META-INF/faces-config.xml
13:29:12,619 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/richfaces-impl-3.3.0.GA.jar/META-INF/faces-config.xml
13:29:12,624 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/jboss-seam-ui-2.1.0.SP1.jar/META-INF/faces-config.xml
13:29:12,628 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/richfaces-ui-3.3.0.GA.jar/META-INF/faces-config.xml
13:29:12,632 INFO  [STDOUT] ******************************************

Without WhatsUpDawg.ear you get:

13:32:41,564 INFO  [STDOUT] ******************************************
13:32:41,568 INFO  [STDOUT] ** Resource Paths for META-INF/faces-config.xml:
13:32:41,602 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/org.jboss.seam-jboss-seam-2.1.0.SP1.jar/META-INF/faces-config.xml
13:32:41,606 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/jsf-facelets-1.1.15.B1.jar/META-INF/faces-config.xml
13:32:41,611 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/jboss-seam-debug-2.1.0.SP1.jar/META-INF/faces-config.xml
13:32:41,617 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/richfaces-impl-3.3.0.GA.jar/META-INF/faces-config.xml
13:32:41,622 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/jboss-seam-ui-2.1.0.SP1.jar/META-INF/faces-config.xml
13:32:41,627 INFO  [STDOUT] vfszip:/C:/jboss-5.1.0.GA.jdk6/jboss-5.1.0.GA/server/default/deploy/admin-console.war/WEB-INF/lib/richfaces-ui-3.3.0.GA.jar/META-INF/faces-config.xml
13:32:41,631 INFO  [STDOUT] ******************************************

To see this result, just add the attached class to /admin-console/WEB-INF/lib/classes.  Then put this in /admin-console/WEB-INF/web.xml:

    <listener>
       <listener-class>org.jboss.jbas7032.PrintResourcePathContextListener</listener-class>
    </listener>

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 13:41:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 14 Jul 2009 13:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <1305499751.1247593289526.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert updated JBAS-7032:
-------------------------------

    Attachment: PrintResourcePathContextListener.java


> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: PrintResourcePathContextListener.class, PrintResourcePathContextListener.java, WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 15:55:29 2009
From: jira-events at lists.jboss.org (Alexander Smirnov (JIRA))
Date: Tue, 14 Jul 2009 15:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2432)
 PortletRequestDispatcher does
 not execute 'forward' method during resource request.
Message-ID: <2086542322.1247601329145.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

PortletRequestDispatcher does not execute 'forward' method during resource request.
-----------------------------------------------------------------------------------

                 Key: JBPORTAL-2432
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2432
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core
         Environment: Jboss Portal 2.7 built from http://anonsvn.jboss.org/repos/portal/branches/JBoss_Portal_Branch_2_7 revision 13553 / Jboss AS 4.2.3.GA
            Reporter: Alexander Smirnov


By default, GenericFacesPortlet uses PortletRequestDispatcher.forward method to serve resources during resource requests. The code is:
	/**
	 * Default resource serving.
	 * <p>
	 * The default implemention of this method is to call a
	 * RequestDispatcher.foward with the ResourceID of the ResourceRequest.
	 * <p>
	 * If no ResourceID is set on the resource URL the default implementation
	 * does nothing.
	 * 
	 * @since 2.0
	 */
	public void serveResource(ResourceRequest request, ResourceResponse response) throws PortletException, IOException {
		if (request.getResourceID() != null) {
			PortletRequestDispatcher rd = getPortletConfig().getPortletContext().getRequestDispatcher(
					request.getResourceID());
			if (rd != null)
				rd.forward(request, response);
		}
	}
Never that code nor custom portletBridge code that uses 'forward' method doesn't work in Jboss Portal but works properly in other Portlet 2.0 implementations.
The same PortletRequestDispatcher.forward method works properly during render request.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 15:59:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Tue, 14 Jul 2009 15:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <1027816382.1247601569385.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476285#action_12476285 ] 

Ales Justin commented on JBAS-7032:
-----------------------------------

Did you try this against my latest WB fix (WBINT-16)?

Or why exactly does admin-console get that faces/ added from WBUrlIntegrationDeployer?
Or how does that resource creep in?

btw: did we fix that admin-console CL isolation issue?
(by having proper jboss-web.xml)

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: PrintResourcePathContextListener.class, PrintResourcePathContextListener.java, WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 16:14:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 14 Jul 2009 16:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-99) Create extensible
 AS Server implementation base
In-Reply-To: <1375381167.1247203301607.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <162918837.1247602469130.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-99.
---------------------------------------

    Resolution: Done


> Create extensible AS Server implementation base
> -----------------------------------------------
>
>                 Key: JBBOOT-99
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-99
>             Project: JBoss Bootstrap
>          Issue Type: Task
>          Components: impl-as
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 2.0.0-beta-1 
>
>
> JBossASEmbeddedServerImpl in the EMB project currently extends from JBossASServerImpl, which provides no generics to allow for covarient return.  As a result, the method chaining functions come back as JBossASServer instead of JBossASEmbeddedServer.  
> Make an extensible AS server implementation which keeps the generics chain alive.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 16:16:42 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 14 Jul 2009 16:16:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <976238844.1247602602303.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476287#action_12476287 ] 

Stan Silvert commented on JBAS-7032:
------------------------------------

No, I haven't tried it with the WBINT-16 fix.

I don't know exactly how the resource creeps in.  I can only conclude that it leaks from the deployment of WhatsUpDawg.ear.  So I'm guessing that when the WBDeployer puts /webbeans.deployer/lib-int/faces on the classpath then that makes it visible to all deployments.

Isolation of admin-console doesn't solve the problem since we can't ask everyone to isolate their apps just because a WebBeans app is running in the same AS instance.



> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: PrintResourcePathContextListener.class, PrintResourcePathContextListener.java, WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 16:43:29 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 14 Jul 2009 16:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <785223743.1247604209424.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-7032:
---------------------------------


RE: btw: did we fix that admin-console CL isolation issue? (by having proper jboss-web.xml)
The admin-console.war includes a jboss-web.xml with the following: 
<class-loading>
        <loader-repository>
            org.jboss.on:loader=embedded
            <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
        </loader-repository>
    </class-loading>

I have been looking at different app packaging to determine if there are other issues besides applications with web beans.  In addition to the web beans application, I have found that an EAR which includes SEAM/RF library jars in the EAR/lib directory *without* a jboss-app.xml (and EAR isolation is set to false by default in ear-deployer-jboss-beans.xml) also has the same problem; specifically, picking up another deployment's faces-config.xml .  Using Stan's ServletContextListener, the output with jboss-seam-booking (with jboss-app.xml removed):

2009-07-14 15:38:54,608 INFO  [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (main) deploy, ctxPath=/admin-console
2009-07-14 15:38:54,705 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (main) Initializing Mojarra (1.2_12-b01-FCS) for context '/admin-console'

2009-07-14 15:38:58,168 INFO  [STDOUT] (main) ******************************************
2009-07-14 15:38:58,168 INFO  [STDOUT] (main) ** Resource Paths for META-INF/faces-config.xml:
2009-07-14 15:38:58,201 INFO  [STDOUT] (main) vfszip:/work/EAP5/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/admin-console.war/WEB-INF/lib/richfaces-impl-3.3.0.GA.jar/META-INF/faces-config.xml
2009-07-14 15:38:58,202 INFO  [STDOUT] (main) vfszip:/work/EAP5/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/jboss-seam-booking.ear/jboss-seam.jar/META-INF/faces-config.xml
2009-07-14 15:38:58,202 INFO  [STDOUT] (main) vfszip:/work/EAP5/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/admin-console.war/WEB-INF/lib/jboss-seam-ui-2.1.0.SP1.jar/META-INF/faces-config.xml
2009-07-14 15:38:58,202 INFO  [STDOUT] (main) vfszip:/work/EAP5/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/admin-console.war/WEB-INF/lib/richfaces-ui-3.3.0.GA.jar/META-INF/faces-config.xml
2009-07-14 15:38:58,202 INFO  [STDOUT] (main) vfszip:/work/EAP5/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/admin-console.war/WEB-INF/lib/org.jboss.seam-jboss-seam-2.1.0.SP1.jar/META-INF/faces-config.xml
2009-07-14 15:38:58,202 INFO  [STDOUT] (main) vfszip:/work/EAP5/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/admin-console.war/WEB-INF/lib/jsf-facelets-1.1.15.B1.jar/META-INF/faces-config.xml
2009-07-14 15:38:58,202 INFO  [STDOUT] (main) vfszip:/work/EAP5/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/admin-console.war/WEB-INF/lib/jboss-seam-debug-2.1.0.SP1.jar/META-INF/faces-config.xml


Setting EAR isolation to true in ear-deployer-jboss-beans.xml or providing a jboss-app.xml, the faces-config.xml from the jboss-seam-booking app is not found and both apps work together.    

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: PrintResourcePathContextListener.class, PrintResourcePathContextListener.java, WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 16:53:29 2009
From: jira-events at lists.jboss.org (Wesley Hales (JIRA))
Date: Tue, 14 Jul 2009 16:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2432)
 PortletRequestDispatcher
 does not execute 'forward' method during resource request.
In-Reply-To: <2086542322.1247601329145.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1288278713.1247604809197.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476292#action_12476292 ] 

Wesley Hales commented on JBPORTAL-2432:
----------------------------------------

There are no tests for PortletRequestDispatcher.forward and there needs to be a test assessing that forward should work.
For now we will use the include method as a workaround.

Thomas, can you help out with this or re-assign?

> PortletRequestDispatcher does not execute 'forward' method during resource request.
> -----------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-2432
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2432
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>         Environment: Jboss Portal 2.7 built from http://anonsvn.jboss.org/repos/portal/branches/JBoss_Portal_Branch_2_7 revision 13553 / Jboss AS 4.2.3.GA
>            Reporter: Alexander Smirnov
>
> By default, GenericFacesPortlet uses PortletRequestDispatcher.forward method to serve resources during resource requests. The code is:
> 	/**
> 	 * Default resource serving.
> 	 * <p>
> 	 * The default implemention of this method is to call a
> 	 * RequestDispatcher.foward with the ResourceID of the ResourceRequest.
> 	 * <p>
> 	 * If no ResourceID is set on the resource URL the default implementation
> 	 * does nothing.
> 	 * 
> 	 * @since 2.0
> 	 */
> 	public void serveResource(ResourceRequest request, ResourceResponse response) throws PortletException, IOException {
> 		if (request.getResourceID() != null) {
> 			PortletRequestDispatcher rd = getPortletConfig().getPortletContext().getRequestDispatcher(
> 					request.getResourceID());
> 			if (rd != null)
> 				rd.forward(request, response);
> 		}
> 	}
> Never that code nor custom portletBridge code that uses 'forward' method doesn't work in Jboss Portal but works properly in other Portlet 2.0 implementations.
> The same PortletRequestDispatcher.forward method works properly during render request.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 16:53:29 2009
From: jira-events at lists.jboss.org (Wesley Hales (JIRA))
Date: Tue, 14 Jul 2009 16:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-2432)
 PortletRequestDispatcher
 does not execute 'forward' method during resource request.
In-Reply-To: <2086542322.1247601329145.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2010562096.1247604809304.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wesley Hales reassigned JBPORTAL-2432:
--------------------------------------

    Assignee: Thomas Heute


> PortletRequestDispatcher does not execute 'forward' method during resource request.
> -----------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-2432
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2432
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>         Environment: Jboss Portal 2.7 built from http://anonsvn.jboss.org/repos/portal/branches/JBoss_Portal_Branch_2_7 revision 13553 / Jboss AS 4.2.3.GA
>            Reporter: Alexander Smirnov
>            Assignee: Thomas Heute
>
> By default, GenericFacesPortlet uses PortletRequestDispatcher.forward method to serve resources during resource requests. The code is:
> 	/**
> 	 * Default resource serving.
> 	 * <p>
> 	 * The default implemention of this method is to call a
> 	 * RequestDispatcher.foward with the ResourceID of the ResourceRequest.
> 	 * <p>
> 	 * If no ResourceID is set on the resource URL the default implementation
> 	 * does nothing.
> 	 * 
> 	 * @since 2.0
> 	 */
> 	public void serveResource(ResourceRequest request, ResourceResponse response) throws PortletException, IOException {
> 		if (request.getResourceID() != null) {
> 			PortletRequestDispatcher rd = getPortletConfig().getPortletContext().getRequestDispatcher(
> 					request.getResourceID());
> 			if (rd != null)
> 				rd.forward(request, response);
> 		}
> 	}
> Never that code nor custom portletBridge code that uses 'forward' method doesn't work in Jboss Portal but works properly in other Portlet 2.0 implementations.
> The same PortletRequestDispatcher.forward method works properly during render request.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 16:57:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 14 Jul 2009 16:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1011) Release JGroups
	2.6.11
Message-ID: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Release JGroups 2.6.11
----------------------

                 Key: JGRP-1011
                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.6.11
            Reporter: Richard Achmatowicz
            Assignee: Richard Achmatowicz


This release is required for EAP.

Here are the fixes which are so far logged against this release:
Release Notes - JGroups - Version 2.6.11
** Bug
   * [JGRP-912] - Failed to parse the jgroups.xml file
   * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
   * [JGRP-985] - Flush and join problems during constant node failures and constant joins
   * [JGRP-986] - FLUSH: relax event sequencing for a joining member
   * [JGRP-997] - AUTH: incorrect matching of src against memberList
   * [JGRP-1000] - COMPRESS corrupts some messages
   * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
** Task
   * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
   * [JGRP-1004] - GroupRequest: don't ignore InterruptedException

Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
 
There are other IPv6 relared issues which also should be addressed, in particular JGRP-956.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 17:18:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 14 Jul 2009 17:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-100) Upgrade
 dependencies as part of 2.0.0-alpha-X release chain
Message-ID: <472570314.1247606309632.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade dependencies as part of 2.0.0-alpha-X release chain
-----------------------------------------------------------

                 Key: JBBOOT-100
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-100
             Project: JBoss Bootstrap
          Issue Type: Task
          Components: impl-as, impl-mc, spi
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 17:52:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 14 Jul 2009 17:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <593991298.1247608349240.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1011:
--------------------------------------

    Description: 
This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.

Here are the fixes which are so far logged against this release:
Release Notes - JGroups - Version 2.6.11
** Bug
   * [JGRP-912] - Failed to parse the jgroups.xml file
   * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
   * [JGRP-985] - Flush and join problems during constant node failures and constant joins
   * [JGRP-986] - FLUSH: relax event sequencing for a joining member
   * [JGRP-997] - AUTH: incorrect matching of src against memberList
   * [JGRP-1000] - COMPRESS corrupts some messages
   * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
** Task
   * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
   * [JGRP-1004] - GroupRequest: don't ignore InterruptedException

Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
 
There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

  was:
This release is required for EAP.

Here are the fixes which are so far logged against this release:
Release Notes - JGroups - Version 2.6.11
** Bug
   * [JGRP-912] - Failed to parse the jgroups.xml file
   * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
   * [JGRP-985] - Flush and join problems during constant node failures and constant joins
   * [JGRP-986] - FLUSH: relax event sequencing for a joining member
   * [JGRP-997] - AUTH: incorrect matching of src against memberList
   * [JGRP-1000] - COMPRESS corrupts some messages
   * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
** Task
   * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
   * [JGRP-1004] - GroupRequest: don't ignore InterruptedException

Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
 
There are other IPv6 relared issues which also should be addressed, in particular JGRP-956.



> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 17:58:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 14 Jul 2009 17:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1704699721.1247608709092.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476296#action_12476296 ] 

Richard Achmatowicz commented on JGRP-1011:
-------------------------------------------

Applied changes to testsuite for IPv6 testing.
Fixed ConnectionTableTest and GossipRouterTest to eliminate dependence on localhost.


> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 18:32:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 14 Jul 2009 18:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7098) Upgrade
 jboss-bootstrap dependencies and refactor to match
Message-ID: <1310709585.1247610749408.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade jboss-bootstrap dependencies and refactor to match
----------------------------------------------------------

                 Key: JBAS-7098
                 URL: https://jira.jboss.org/jira/browse/JBAS-7098
             Project: JBoss Application Server
          Issue Type: Thirdparty Change
      Security Level: Public (Everyone can see)
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


With JBBOOT-99 we introduce an extensible JBossASBasedServer which must be used such that Embedded can take advantage of AS as well.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 18:38:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Tue, 14 Jul 2009 18:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7098) Upgrade
 jboss-bootstrap dependencies and refactor to match
In-Reply-To: <1310709585.1247610749408.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <840801243.1247611109147.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476298#action_12476298 ] 

Andrew Lee Rubinger commented on JBAS-7098:
-------------------------------------------

Need to merge r91266 into trunk

> Upgrade jboss-bootstrap dependencies and refactor to match
> ----------------------------------------------------------
>
>                 Key: JBAS-7098
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7098
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> With JBBOOT-99 we introduce an extensible JBossASBasedServer which must be used such that Embedded can take advantage of AS as well.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 18:44:29 2009
From: jira-events at lists.jboss.org (John Ament (JIRA))
Date: Tue, 14 Jul 2009 18:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <748704164.1247611469349.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476299#action_12476299 ] 

John Ament commented on JBAS-7032:
----------------------------------

just wondering, can you provide a demo jboss-app.xml that works around this?

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: PrintResourcePathContextListener.class, PrintResourcePathContextListener.java, WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 21:50:29 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 14 Jul 2009 21:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <1620374378.1247622629915.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-7032:
---------------------------------

    Attachment: jboss-app.xml


John, see attached is a jboss-app.xml 

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-app.xml, PrintResourcePathContextListener.class, PrintResourcePathContextListener.java, WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 21:58:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 14 Jul 2009 21:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2412) Update the logging
	framework
Message-ID: <1216275567.1247623109501.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBAS-2412.
-----------------------------

    Fix Version/s:     (was: JBossAS-5.2.0.Beta1)
       Resolution: Done


Merged into 6.x.  Open a new JIRA if a backport to 5.2 is required

> Update the logging framework
> ----------------------------
>
>                 Key: JBAS-2412
>                 URL: https://jira.jboss.org/jira/browse/JBAS-2412
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: Scott M Stark
>            Assignee: David Lloyd
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Its been a long time since we revisted the logging framework and the use of log4j as the default. I looked at having better seamless integration with the jdk java.util.logging framework using a port of the log4j appenders/layout to jdk handlers/formatters and the initial prototype is in head as mentioned in the linked forum thread.
> We need to reevaluate what the default logging implementation should be along with what updates the Log4jService needs. Some things to think about:
> 1. Using a log4j implementation that does not suffer from the current deadlock problem
> 2. How to nlog4j, slf4j, commons logging fit into the picture
> 3. Generalization of the Log4jService into one that works for whatever the default implementation is
> 3a. Add support for redirecting stderr, stdout to seperate log files instead of all loggers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 22:00:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 14 Jul 2009 22:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-6097) Move Log4jService
 into separate project
In-Reply-To: <18917230.1224054440898.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1949700421.1247623229585.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBAS-6097.
-----------------------------

    Fix Version/s:     (was: JBossAS-5.2.0.Beta1)
       Resolution: Done


> Move Log4jService into separate project
> ---------------------------------------
>
>                 Key: JBAS-6097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6097
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.0.0.CR2
>            Reporter: Scott M Stark
>            Assignee: David Lloyd
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> To pull the Log4jService into a bootstrap beans file it needs to be moved out of the jboss.jar and properly pojoized.
> The org.jboss.logging package from the server module is being moved to:
> https://svn.jboss.org/repos/jbossas/projects/log-services/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 14 22:15:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 14 Jul 2009 22:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6789) Allow applications
 to override logging by placing a log4j.xml inside it
In-Reply-To: <4502880.1239799773655.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1648839381.1247624129292.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476305#action_12476305 ] 

David Lloyd commented on JBAS-6789:
-----------------------------------

Do you require support specifically for log4j deployments?  Or simply the ability for each deployment to provide its own logging configuration?

> Allow applications to override logging by placing a log4j.xml inside it
> -----------------------------------------------------------------------
>
>                 Key: JBAS-6789
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6789
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: Pete Muir
>            Assignee: David Lloyd
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 01:10:49 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 01:10:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1401) Unverified:
 Restarting a Queue will delete persistent messages in the queue.
In-Reply-To: <1348241.1216341592381.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <411598124.1247634649009.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1401:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> Unverified: Restarting a Queue will delete persistent messages in the queue.
> ----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1401
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1401
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3
>            Reporter: Jay Howell
>            Assignee: Howard Gao
>
> Restarting a queue in a running server will delete persistent messages out of the database.  This bug was found while troubleshooting a case.  When a customer restarted the queues, they noticed that all of the persistent messages in the database were gone.  I have yet to verify this and will verify as soon as possible.  I wanted to make sure that I didn't forget to put it in.  So at this point this is an unverified bug. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 01:14:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 01:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1401) Unverified:
 Restarting a Queue will delete persistent messages in the queue.
In-Reply-To: <1348241.1216341592381.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1872477410.1247634869468.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1401:
------------------------------------

      Component/s: Configuration and Management
    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> Unverified: Restarting a Queue will delete persistent messages in the queue.
> ----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1401
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1401
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.4.0.SP3
>            Reporter: Jay Howell
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Restarting a queue in a running server will delete persistent messages out of the database.  This bug was found while troubleshooting a case.  When a customer restarted the queues, they noticed that all of the persistent messages in the database were gone.  I have yet to verify this and will verify as soon as possible.  I wanted to make sure that I didn't forget to put it in.  So at this point this is an unverified bug. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 01:33:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 01:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <531380494.1247636009698.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1685:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.3.GA
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 01:33:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 01:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1435) Connection
 drop cannot recover JMSSession
In-Reply-To: <31561080.1225686021029.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1713084271.1247636009525.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476310#action_12476310 ] 

Howard Gao commented on JBMESSAGING-1435:
-----------------------------------------


Hi Chris,

To me it sounds like an JBoss ESB feature request. So probably we will reject it and you can report this to ESB team.



> Connection drop cannot recover JMSSession
> -----------------------------------------
>
>                 Key: JBMESSAGING-1435
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1435
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>         Environment: jbossesb-server-4.4.GA
> Windows XP
>            Reporter: Chris Au
>            Assignee: Tim Fox
>
> I used JMSRouter to route message to a SonicMQ, it works fine. But I just tried to figure out the exception handling method and tried to manually drop the connection from ESB Client to SonicMQ. But after I dropped the connection, exception raised as follows : 
> javax.jms.IllegalStateException: The session is closed.
> 	at progress.message.jimpl.Session.getJMSObjectClosedException(Unknown Source)
> 	at progress.message.jimpl.Session.createTextMessage(Unknown Source)
> 	at org.jboss.internal.soa.esb.rosetta.pooling.JmsSession.createTextMessage(JmsSession.java:210)
> 	at org.jboss.soa.esb.actions.routing.JMSRouter.createJMSMessageWithObjectType(JMSRouter.java:262)
> 	at org.jboss.soa.esb.actions.routing.JMSRouter.route(JMSRouter.java:232)
> 	at org.jboss.soa.esb.actions.routing.JMSRouter.process(JMSRouter.java:211)
> 	at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:316)
> 	at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:530)
> 	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)
> Is it an expected behavior that it will not do auto-retry? As I could not find any "isSessionClosed()" kind method to check if the session is closed. 
> On the other hand, I also listens to SonicMQ, the connection will automatically recover once I manually drop the connection session. Could the similar be implemented in JmsSender ?
> Another issue is......is it possible to provide any clue for the cause of the exception : 
> ERROR [org.jboss.jms.client.container.ClosedInterceptor] ClosedInterceptor.ClientSessionDelegate[ya-ie6ih2nf-1-9wwug2nf-klr89h-m4u4js4]: method getAcknowledgeMode() did not go through, the interceptor is CLOSED  ? 
> Thanks a lot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 01:38:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 01:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1436)
 MessageRedeliverer for DLQ
In-Reply-To: <30004743.1225773383675.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <422471645.1247636309233.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476311#action_12476311 ] 

Howard Gao commented on JBMESSAGING-1436:
-----------------------------------------

Hi Chris,

This should be an JBOSS ESP issue, please raise the issue against the ESB project. Thanks.


> MessageRedeliverer for DLQ
> --------------------------
>
>                 Key: JBMESSAGING-1436
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1436
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>         Environment: JBossESB-server-4.4.GA
> WindowsXP
>            Reporter: Chris Au
>            Assignee: Tim Fox
>
> I have seen the source code of MessageRedeliverer, which defaults to be resending message for RDLVR classification. But I see there shouldn't be difficult to modify so that it could support redelivery of message for DLQ. (We may want to try the DLQ once per day or even once a week automatically so as to cleanup accumulated DLQ messages).
> I also noticed that the DBMessageStoreImpl.resend function only supports for RDLVR classification because of the checking that 
> delete(uuid, RedeliverStore.CLASSIFICATION_RDLVR, con)==1 
> So even if I manually invoke the internal redeliverer service with a message having header property : 
> org.jboss.soa.esb.messagestore.classification = DLQ
> the redelivery will not success.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 01:46:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 01:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1287) SOA-P test
 suite failures
In-Reply-To: <23570323.1210850002522.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <711205247.1247636789300.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476312#action_12476312 ] 

Howard Gao commented on JBMESSAGING-1287:
-----------------------------------------

Hi Aleksandar,

This jira is a little out dated, can you give some update? for example, is it still failing on your environment and what's the version of JBM are you using?

Thanks
Howard


> SOA-P test suite failures
> -------------------------
>
>                 Key: JBMESSAGING-1287
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1287
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP01
>            Reporter: Aleksandar Kostadinov
>            Assignee: Tim Fox
>
> I'm running the JBM test suite against the binaries in the SOA-P Platform 4.2 CP01. I see 4 failures. 
>     * TEST-org.jboss.test.messaging.jms.bridge.BridgeTest-Remote-bisocket.xml.
>     * org.jboss.test.messaging.jms.clustering.MultipleFailoverTest(Clustering).testFailoverFloodTwoServers
>     * org.jboss.test.messaging.jms.clustering.NoFailoverTest(Clustering).testCrashNoFailover
>     * org.jboss.test.messaging.jms.ManifestTest.testManifestEntries
> Failure details in here http://hudson.qa.jboss.com/hudson/job/jboss-soa-platform-JBM-testsuite/73/testReport/
> 3 of the failures are timeout (see console log for BridgeTest). We are running on a 2 CPU DualCore physical machine so system speed should not be an issue. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 01:48:42 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 01:48:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1287) SOA-P test
	suite failures
In-Reply-To: <23570323.1210850002522.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1619009699.1247636922213.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1287:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> SOA-P test suite failures
> -------------------------
>
>                 Key: JBMESSAGING-1287
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1287
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP01
>            Reporter: Aleksandar Kostadinov
>            Assignee: Howard Gao
>
> I'm running the JBM test suite against the binaries in the SOA-P Platform 4.2 CP01. I see 4 failures. 
>     * TEST-org.jboss.test.messaging.jms.bridge.BridgeTest-Remote-bisocket.xml.
>     * org.jboss.test.messaging.jms.clustering.MultipleFailoverTest(Clustering).testFailoverFloodTwoServers
>     * org.jboss.test.messaging.jms.clustering.NoFailoverTest(Clustering).testCrashNoFailover
>     * org.jboss.test.messaging.jms.ManifestTest.testManifestEntries
> Failure details in here http://hudson.qa.jboss.com/hudson/job/jboss-soa-platform-JBM-testsuite/73/testReport/
> 3 of the failures are timeout (see console log for BridgeTest). We are running on a 2 CPU DualCore physical machine so system speed should not be an issue. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 01:53:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 01:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1287) SOA-P test
	suite failures
In-Reply-To: <23570323.1210850002522.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1836456994.1247637209228.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1287:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> SOA-P test suite failures
> -------------------------
>
>                 Key: JBMESSAGING-1287
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1287
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP01
>            Reporter: Aleksandar Kostadinov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> I'm running the JBM test suite against the binaries in the SOA-P Platform 4.2 CP01. I see 4 failures. 
>     * TEST-org.jboss.test.messaging.jms.bridge.BridgeTest-Remote-bisocket.xml.
>     * org.jboss.test.messaging.jms.clustering.MultipleFailoverTest(Clustering).testFailoverFloodTwoServers
>     * org.jboss.test.messaging.jms.clustering.NoFailoverTest(Clustering).testCrashNoFailover
>     * org.jboss.test.messaging.jms.ManifestTest.testManifestEntries
> Failure details in here http://hudson.qa.jboss.com/hudson/job/jboss-soa-platform-JBM-testsuite/73/testReport/
> 3 of the failures are timeout (see console log for BridgeTest). We are running on a 2 CPU DualCore physical machine so system speed should not be an issue. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 01:55:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 01:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1478) inconsistent
 test suite performance
In-Reply-To: <25748306.1231170954442.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <79015774.1247637329211.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1478:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> inconsistent test suite performance
> -----------------------------------
>
>                 Key: JBMESSAGING-1478
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1478
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Tests and Performance
>    Affects Versions:  1.4.0.SP3.CP04
>            Reporter: Aleksandar Kostadinov
>            Assignee: Howard Gao
>
> I see inconsistent performance running the JBM test suite. Here I have 2 builds on the same physical machine (windows), using local disk storage so environment should be pretty stable.
> The mysql database is shared but I doubt it is the culprit. 
> I run the test suite with the following options:
> property( name: "functional.tests.database", value: dbname )
> property( name: "stress.tests.database", value: dbname )
> property( name: "clustering.tests.database", value: dbname )
> property( name: "test.target", value: "report" )
> property( name: "test.bind.address", value: properties["env.MYTESTIP_1"] )
> property( name: "jboss.messaging.groupname", value: properties["env.BUILD_TAG"])                                                                               
> property( name: "jboss.messaging.datachanneludpaddress", value: properties["env.MCAST_ADDR"] )
> property( name: "jboss.messaging.controlchanneludpaddress", value: properties["env.MCAST_ADDR"] )
> Are there any other options I can add to increase isolation from other processes in the same LAN?
> Would you be able to look at these 2 builds and based on the logs, say why is the first one taking longer and eventually timeout?
> http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/163/
> http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/164/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 02:04:29 2009
From: jira-events at lists.jboss.org (Aleksandar Kostadinov (JIRA))
Date: Wed, 15 Jul 2009 02:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1287) SOA-P test
 suite failures
In-Reply-To: <23570323.1210850002522.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <381146544.1247637869280.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476316#action_12476316 ] 

Aleksandar Kostadinov commented on JBMESSAGING-1287:
----------------------------------------------------

Hallo, as I said in my previous comment the problem is that you have a file called VERSION and you use it to get your version string. So if any other library has such file, it can be read instead of yours and probably cause problems.

I'm not sure about what should be done. Two suggestions below:
1. Rename that file to JBM_VERSION or some other name that is less likely being used by some other project.
2. Verify that the deployment in SOA-P is such that this can never cause a problem. Given that JBM seems to be working in the other testing this is likely to be true. But I'm not sure if in any customer deployment scenarios this can't get them in trouble.

Hope this makes sense.

> SOA-P test suite failures
> -------------------------
>
>                 Key: JBMESSAGING-1287
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1287
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP01
>            Reporter: Aleksandar Kostadinov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> I'm running the JBM test suite against the binaries in the SOA-P Platform 4.2 CP01. I see 4 failures. 
>     * TEST-org.jboss.test.messaging.jms.bridge.BridgeTest-Remote-bisocket.xml.
>     * org.jboss.test.messaging.jms.clustering.MultipleFailoverTest(Clustering).testFailoverFloodTwoServers
>     * org.jboss.test.messaging.jms.clustering.NoFailoverTest(Clustering).testCrashNoFailover
>     * org.jboss.test.messaging.jms.ManifestTest.testManifestEntries
> Failure details in here http://hudson.qa.jboss.com/hudson/job/jboss-soa-platform-JBM-testsuite/73/testReport/
> 3 of the failures are timeout (see console log for BridgeTest). We are running on a 2 CPU DualCore physical machine so system speed should not be an issue. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 02:06:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1513) Database
 maintenance scripts
In-Reply-To: <19858050.1234906484708.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <554366462.1247637989213.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476317#action_12476317 ] 

Howard Gao commented on JBMESSAGING-1513:
-----------------------------------------

Hi Len,

Can you brief me what this script for? I had a look at SOA-310 but I don't know much about SOA project. 

Thanks.
Howard


> Database maintenance scripts
> ----------------------------
>
>                 Key: JBMESSAGING-1513
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1513
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>    Affects Versions: 1.4.2.GA.SP1
>            Reporter: Len DiMaggio
>            Assignee: Tim Fox
>
> Project JIRA for SOA-P platform JIRA: https://jira.jboss.org/jira/browse/SOA-310

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 02:20:30 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:20:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1594) Provide
 support for a List of Strings (in StreamMessage) with a size > 64K
In-Reply-To: <19407645.1239259282444.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1540760579.1247638830095.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1594:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> Provide support for a List of Strings (in StreamMessage) with a size > 64K
> --------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1594
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1594
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3
>            Reporter: Colin Mondesir
>            Assignee: Howard Gao
>
> Looking at the code, there is support for 'longstring' for java.lang.String. But that doesn't happen for a List of Strings.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 02:20:30 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:20:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1513) Database
 maintenance scripts
In-Reply-To: <19858050.1234906484708.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <712891165.1247638830206.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1513:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA
         Assignee: Howard Gao  (was: Tim Fox)


> Database maintenance scripts
> ----------------------------
>
>                 Key: JBMESSAGING-1513
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1513
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>    Affects Versions: 1.4.2.GA.SP1
>            Reporter: Len DiMaggio
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Project JIRA for SOA-P platform JIRA: https://jira.jboss.org/jira/browse/SOA-310

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 02:23:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1594) Provide
 support for a List of Strings (in StreamMessage) with a size > 64K
In-Reply-To: <19407645.1239259282444.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <216924033.1247639009151.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1594:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> Provide support for a List of Strings (in StreamMessage) with a size > 64K
> --------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1594
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1594
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3
>            Reporter: Colin Mondesir
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Looking at the code, there is support for 'longstring' for java.lang.String. But that doesn't happen for a List of Strings.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 02:26:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1610) expose
 jbossInternalLifecycle method on jms destination mbeans
In-Reply-To: <27082798.1240932886857.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1551577264.1247639189797.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1610:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> expose jbossInternalLifecycle method on jms destination mbeans
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-1610
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1610
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: AS Integration
>    Affects Versions: 1.4.3.GA
>            Reporter: Emanuel Muckenhuber
>            Assignee: Tim Fox
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Currently the Queue and Topic xmbean definitions don't expose the jbossInternalLifecycle(String method). This method is needed that the lifecycle and state changes of a mbean are handled by microcontainer (AS5). Otherwise profileservice cannot determine the current state and a stopped jms destination would be still exposed as running to JON/JOPR.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 02:28:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1610) expose
 jbossInternalLifecycle method on jms destination mbeans
In-Reply-To: <27082798.1240932886857.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1960517372.1247639309898.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1610:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> expose jbossInternalLifecycle method on jms destination mbeans
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-1610
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1610
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: AS Integration
>    Affects Versions: 1.4.3.GA
>            Reporter: Emanuel Muckenhuber
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Currently the Queue and Topic xmbean definitions don't expose the jbossInternalLifecycle(String method). This method is needed that the lifecycle and state changes of a mbean are handled by microcontainer (AS5). Otherwise profileservice cannot determine the current state and a stopped jms destination would be still exposed as running to JON/JOPR.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 02:28:29 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 15 Jul 2009 02:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-534) Maven repository
	aggregation
Message-ID: <1192295848.1247639309938.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Maven repository aggregation
----------------------------

                 Key: JBBUILD-534
                 URL: https://jira.jboss.org/jira/browse/JBBUILD-534
             Project: JBoss Build System
          Issue Type: Task
          Components: Maven Builds
            Reporter: Thomas Diesler


There are a number of projects which have dependencies on non-jboss
maven repos (jboss-osgi is one of them)

http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235779#4235779

I believe, this issue is general enough to have proper repo aggregation 
setup somehow

Here is a link to some aggregators

http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix

Is this a way you want to move forward or should we stick with manually copying individual artefacts to the jboss repo? 
Please note, that by doing so (i.e. mvn deploy-file) you loose the original pom and hence the information on transitive dependencies.

http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 02:30:29 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 15 Jul 2009 02:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-534) Maven repository
	aggregation
In-Reply-To: <1192295848.1247639309938.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <591807180.1247639429597.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476318#action_12476318 ] 

Thomas Diesler commented on JBBUILD-534:
----------------------------------------

Please also note, that even if you preserve the original POM on 'deploy-file' it is likely that the deployed file itself has dependencies on artefacts in other repositories.

> Maven repository aggregation
> ----------------------------
>
>                 Key: JBBUILD-534
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-534
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Thomas Diesler
>
> There are a number of projects which have dependencies on non-jboss
> maven repos (jboss-osgi is one of them)
> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235779#4235779
> I believe, this issue is general enough to have proper repo aggregation 
> setup somehow
> Here is a link to some aggregators
> http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix
> Is this a way you want to move forward or should we stick with manually copying individual artefacts to the jboss repo? 
> Please note, that by doing so (i.e. mvn deploy-file) you loose the original pom and hence the information on transitive dependencies.
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 02:32:42 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 15 Jul 2009 02:32:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-534) Maven repository
	aggregation
In-Reply-To: <1192295848.1247639309938.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <219421027.1247639562266.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476319#action_12476319 ] 

Thomas Diesler commented on JBBUILD-534:
----------------------------------------

Max sais:

Paul G. and I are exploring to setup a Nexus repository 
manager....needed to get order in the jboss maven chaos we got right now 
;) Plus looking into
getting a similar setup for the productized binaries.

Problem right now is time and machine availability constraints - if you 
want to help out with this ping me :)


> Maven repository aggregation
> ----------------------------
>
>                 Key: JBBUILD-534
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-534
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Thomas Diesler
>
> There are a number of projects which have dependencies on non-jboss
> maven repos (jboss-osgi is one of them)
> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235779#4235779
> I believe, this issue is general enough to have proper repo aggregation 
> setup somehow
> Here is a link to some aggregators
> http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix
> Is this a way you want to move forward or should we stick with manually copying individual artefacts to the jboss repo? 
> Please note, that by doing so (i.e. mvn deploy-file) you loose the original pom and hence the information on transitive dependencies.
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 02:45:29 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 15 Jul 2009 02:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-534) Maven repository
	aggregation
In-Reply-To: <1192295848.1247639309938.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1762110903.1247640329327.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476320#action_12476320 ] 

Thomas Diesler commented on JBBUILD-534:
----------------------------------------

Generally, I'd like to mention again that 'deploy-file' is not good  solution because of 

* with the generated POM you loose all info about transitive dependencies, etc.

* when you preserve/deploy the original POM you also deploy the dependencies on other repos

* the transitive enclosure of information for (groupId+artifactId+version+classifier) should be equal independent of the repo where you get the artifact from


> Maven repository aggregation
> ----------------------------
>
>                 Key: JBBUILD-534
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-534
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Thomas Diesler
>
> There are a number of projects which have dependencies on non-jboss
> maven repos (jboss-osgi is one of them)
> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235779#4235779
> I believe, this issue is general enough to have proper repo aggregation 
> setup somehow
> Here is a link to some aggregators
> http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix
> Is this a way you want to move forward or should we stick with manually copying individual artefacts to the jboss repo? 
> Please note, that by doing so (i.e. mvn deploy-file) you loose the original pom and hence the information on transitive dependencies.
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 02:45:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1287) SOA-P test
 suite failures
In-Reply-To: <23570323.1210850002522.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1952057494.1247640329439.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476321#action_12476321 ] 

Howard Gao commented on JBMESSAGING-1287:
-----------------------------------------

Hi Aleksandar,

Thanks. Now I understand the issue. I think suggestion 1 is a good option.

Howard


> SOA-P test suite failures
> -------------------------
>
>                 Key: JBMESSAGING-1287
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1287
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP01
>            Reporter: Aleksandar Kostadinov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> I'm running the JBM test suite against the binaries in the SOA-P Platform 4.2 CP01. I see 4 failures. 
>     * TEST-org.jboss.test.messaging.jms.bridge.BridgeTest-Remote-bisocket.xml.
>     * org.jboss.test.messaging.jms.clustering.MultipleFailoverTest(Clustering).testFailoverFloodTwoServers
>     * org.jboss.test.messaging.jms.clustering.NoFailoverTest(Clustering).testCrashNoFailover
>     * org.jboss.test.messaging.jms.ManifestTest.testManifestEntries
> Failure details in here http://hudson.qa.jboss.com/hudson/job/jboss-soa-platform-JBM-testsuite/73/testReport/
> 3 of the failures are timeout (see console log for BridgeTest). We are running on a 2 CPU DualCore physical machine so system speed should not be an issue. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 02:50:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1619) add example
 TCP cluster configuration
In-Reply-To: <8236548.1241645807005.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1083143809.1247640629342.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1619:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA
         Assignee: Howard Gao  (was: Jimmy Wilson)


> add example TCP cluster configuration
> -------------------------------------
>
>                 Key: JBMESSAGING-1619
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1619
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Dennis Reed
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Add an example TCP cluster configuration (commented out) to all the example *-persistence-service.xml files.
> This will make it easier for users who have issues with UDP multicast to configure it to use TCP clustering.
> (The same thing is being done to all the EAP configurations that don't already include this). 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 02:52:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1621) Provide
 complete message ordering in a clustered environment
In-Reply-To: <16554562.1242110266630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1303763371.1247640749261.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1621:
------------------------------------

          Component/s: JMS Clustering
        Fix Version/s: 1.4.0.SP3.CP09
                       1.4.5.GA
    Affects Version/s: 1.4.4.GA
                       1.4.0.SP3.CP08


Put this on-hold untill there is a strong need. Otherwise we encourage users to move to JBM 2.0

> Provide complete message ordering in a clustered environment
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1621
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1621
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Yusuke Yamamoto
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> While JBMESSAGING-1416 states message ordering feature in a singleton configuration, customer is also requesting a complete message ordering feature which is applicable in a clustered environment.
> Here's the background:
> In the case JMS is used, both performance and scalability are priority.
> There is a conflict between scalable JMS implementation and complete message ordering feature since order aware messages cannot be processed concurrently.
> But order unaware queues should be still processed in parallel for better throughput.
> Additionally, there are some cases that no downtime is acceptable. But HA-Singleton requires certain amount of time to fail-over the service to other node.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 02:52:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1676) Jboss
	Messaging deadlock
In-Reply-To: <317741887.1246538691801.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <271856674.1247640749373.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1676:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA
         Assignee: Howard Gao  (was: Tim Fox)


> Jboss Messaging deadlock
> ------------------------
>
>                 Key: JBMESSAGING-1676
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1676
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: AS Integration
>    Affects Versions: 1.4.3.GA
>         Environment: Version:Linux 2.6.18-53.el5
> Description:Linux Operating System
> Traits
> OS Name: Linux
> OS Version: 2.6.18-53.el5
> Architecture: i386
> Distribution Name: CentOS
> Distribution Version: release 5 (Final)
>            Reporter: Daniel Cullender
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Under high concurrent load it appears that jboss messaging gets stuck in the Hashmap.put method which causes the threads to deadlock which in turn causes transaction timeouts.
> We have several mdb's which have max session sizes of 150, we have max strict pool size of 150 and the jboss thread pool size of 50.
> Recently upgraded from jboss AS 4 MQ series to jboss 5 AS with jboss messaging 1.4.3.GA, with JbossMQ  this problem did not occur.
> The stack trace of the problem is as follows :
> Thread: WorkManager(2)-50 : priority:5, demon:true, threadId:147,
> threadState:RUNNABLE
> java.util.HashMap.put(HashMap.java:374)
> java.util.HashSet.add(HashSet.java:200)
> org.jboss.jms.client.state.HierarchicalStateSupport.(HierarchicalStateSupport.java:63)
> org.jboss.jms.client.state.ProducerState.(ProducerState.java:68)
> org.jboss.jms.client.container.StateCreationAspect.handleCreateProducerDelegate(StateCreationAspect.java:180)
> org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateProducerDelegate_30485827.invoke(StateCreationAspect_z_handleCreateProducerDelegate_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.delegate.ClientSessionDelegate.createProducerDelegate(ClientSessionDelegate.java)
> org.jboss.jms.client.JBossSession.createProducer(JBossSession.java:209)
> qut.common.dao.JmsDao.publishMessage(JmsDao.java:66)
> qut.common.dao.JmsDao.publish(JmsDao.java:104)
> qut.order.manager.OrderManagerMBean.publish(OrderManagerMBean.java:156)
> qut.order.manager.OrderManagerMBean.process(OrderManagerMBean.java:98)
> sun.reflect.GeneratedMethodAccessor354.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
> sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
> org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:451)
> org.jboss.ejb3.service.ServiceMBeanDelegate.invoke(ServiceMBeanDelegate.java:215)
> org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> $Proxy1543.process(Unknown Source)
> qut.order.mdb.OrderManagerTradingDataMDBean.onMessage(OrderManagerTradingDataMDBean.java:64)
> sun.reflect.GeneratedMethodAccessor353.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor$InvocationContext.proceed(InvocationContextInterceptor.java:138)
> qut.common.interceptor.ConcurrencyInterceptor.myInterceptor(ConcurrencyInterceptor.java:46)
> sun.reflect.GeneratedMethodAccessor320.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:83)
> org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:70)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:59)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
> sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
> org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:80)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:282)
> org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:270)
> org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:140)
> $Proxy389.onMessage(Unknown Source)
> org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:178)
> org.jboss.jms.client.container.ClientConsumer.callOnMessageStatic(ClientConsumer.java:160)
> org.jboss.jms.client.container.SessionAspect.handleRun(SessionAspect.java:831)
> org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleRun_30485827.invoke(SessionAspect_z_handleRun_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.delegate.ClientSessionDelegate.run(ClientSessionDelegate.java)
> org.jboss.jms.client.JBossSession.run(JBossSession.java:199)
> org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:234)
> org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205)
> org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> java.lang.Thread.run(Thread.java:619)
> Locked synchronizers : 
> - locked <0x535d1e> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> Thread: WorkManager(2)-70 : priority:5, demon:true, threadId:168,
> threadState:RUNNABLE
> java.util.HashMap.put(HashMap.java:374)
> java.util.HashSet.add(HashSet.java:200)
> org.jboss.jms.client.state.HierarchicalStateSupport.(HierarchicalStateSupport.java:63)
> org.jboss.jms.client.state.ProducerState.(ProducerState.java:68)
> org.jboss.jms.client.container.StateCreationAspect.handleCreateProducerDelegate(StateCreationAspect.java:180)
> org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateProducerDelegate_30485827.invoke(StateCreationAspect_z_handleCreateProducerDelegate_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.delegate.ClientSessionDelegate.createProducerDelegate(ClientSessionDelegate.java)
> org.jboss.jms.client.JBossSession.createProducer(JBossSession.java:209)
> qut.common.dao.JmsDao.publishMessage(JmsDao.java:66)
> qut.common.dao.JmsDao.publish(JmsDao.java:104)
> qut.order.manager.OrderManagerMBean.publish(OrderManagerMBean.java:156)
> qut.order.manager.OrderManagerMBean.process(OrderManagerMBean.java:98)
> sun.reflect.GeneratedMethodAccessor354.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
> sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
> org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:451)
> org.jboss.ejb3.service.ServiceMBeanDelegate.invoke(ServiceMBeanDelegate.java:215)
> org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> $Proxy1384.process(Unknown Source)
> qut.order.mdb.OrderManagerTradingDataMDBean.onMessage(OrderManagerTradingDataMDBean.java:64)
> sun.reflect.GeneratedMethodAccessor353.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor$InvocationContext.proceed(InvocationContextInterceptor.java:138)
> qut.common.interceptor.ConcurrencyInterceptor.myInterceptor(ConcurrencyInterceptor.java:46)
> sun.reflect.GeneratedMethodAccessor320.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:83)
> org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:70)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:59)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
> sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
> org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:80)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:282)
> org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:270)
> org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:140)
> $Proxy389.onMessage(Unknown Source)
> org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:178)
> org.jboss.jms.client.container.ClientConsumer.callOnMessageStatic(ClientConsumer.java:160)
> org.jboss.jms.client.container.SessionAspect.handleRun(SessionAspect.java:831)
> org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleRun_30485827.invoke(SessionAspect_z_handleRun_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.delegate.ClientSessionDelegate.run(ClientSessionDelegate.java)
> org.jboss.jms.client.JBossSession.run(JBossSession.java:199)
> org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:234)
> org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205)
> org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> java.lang.Thread.run(Thread.java:619)
> Locked synchronizers : 
> - locked <0x18827b6> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 02:58:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 02:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1461) Number of
 relivery attempts does not match with my settings
In-Reply-To: <4356892.1227708100133.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1985062978.1247641109431.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1461:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA
         Assignee: Howard Gao  (was: Tim Fox)


> Number of relivery attempts does not match with my settings
> -----------------------------------------------------------
>
>                 Key: JBMESSAGING-1461
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1461
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.SP4
>         Environment: JBoss 4.0.4.GA
> Windows server 2003
>            Reporter: Nicolas Laporte
>            Assignee: Howard Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> I set <attribute name="MaxDeliveryAttempts">15</attribute>
> The time-to-live parameter used by the client is 1 hour.
> We call the setRollbackOnly() method of our CMT MDB if an recoverable exception occurrs.
> The number of redelivery is 5. I expected 15.
> Could you tell me if this problem is known and if it is fixed in an upper version ?
> Thanks a lot for your support.
> Nicolas Laporte
> PDF Solutions

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 03:02:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 03:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1615) Programmatic
 way to check the state of a topic
In-Reply-To: <22443752.1241518126593.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1943913816.1247641349227.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1615:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> Programmatic way to check the state of a topic
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1615
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1615
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 1.4.1.GA
>            Reporter: Colin Mondesir
>            Assignee: Howard Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When the deployTopic(String, String) method is called we have found there is a slight delay before the topic is available to create MessageConsumer.
> Is there a programmatic way of checking the state that the topic is in, so that we don't have to wait an arbitrary period of time before creating the Consumer?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 03:04:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 03:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1684) Message
 remain in the queue and do not get dispatched
In-Reply-To: <1603937672.1247553629290.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1090026785.1247641469438.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1684:
------------------------------------

          Component/s: JMS Facade
        Fix Version/s: 1.4.0.SP3.CP09
                       1.4.5.GA
    Affects Version/s: 1.4.3.GA


> Message remain in the queue and do not get dispatched
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1684
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1684
>             Project: JBoss Messaging
>          Issue Type: Quality Risk
>          Components: JMS Facade
>    Affects Versions: 1.4.3.GA
>         Environment: SuSe Linux Enterprise Server 10, Java 1.5.0_11, AS 5 with JBoss Messaging - default installation
>            Reporter: Alexander Marktl
>            Assignee: Howard Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: jms-provider-evaluation.zip
>
>
> I tried to create 10 queues and send 10.000 messages per queue from a single producer per queue to a single consumer per queue. Unfortunately  not all of the messages where delivered, some messages remain in the queues and wait for delivery. The JMX console for example states: 3 messages in the queue, 3 messages pending for delivery. But nothing happens. My receivers don't get these last messages. I don't know if this is a configuration issue or a bug. 
> The queues are named: qname_0 ...qname_n

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 03:04:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 03:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1490) BridgeService
 should be JAAS aware
In-Reply-To: <12562631.1232152144349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1487451183.1247641469635.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1490:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> BridgeService should be JAAS aware
> ----------------------------------
>
>                 Key: JBMESSAGING-1490
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1490
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 1.4.2.GA
>         Environment: n/a
>            Reporter: Nicholas Sayer
>            Assignee: Howard Gao
>            Priority: Optional
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> org.jboss.jms.server.bridge.BridgeService currently requires a username and password for the source and destination. It would be better if it could be configured with a JAAS login context name. This would allow username and password information to be set in, for example, a SecureIdentityLoginModule. For example:
>     <application-policy name = "JmsBridgeRealm">
>        <authentication>
>           <login-module code = "org.jboss.resource.security.SecureIdentityLoginModule" flag = "required">
>              <module-option name = "principal">${bridge.user}</module-option>
>              <module-option name = "userName">${bridge.user}</module-option>
>              <module-option name = "password">${bridge.encryptedPassword}</module-option>
>              <module-option name = "ignoreMissigingMCF">true</module-option>
> <!-- it is a separate bug that you must set managedConnectionFactoryName to something regardless of setting ignoreMissingMCF to true -->
>              <module-option name = "managedConnectionFactoryName">jboss.nonexistent:service=NonExistent,name=NonExistent</module-option>
>           </login-module>
>        </authentication>
>     </application-policy>
> There is undoubtedly a better way to accomplish this (probably to pass the JAAS context directly into the JMS connection factory used to vend connections for the bridge), but we're using this as a crude hack for now:
> import java.util.Set;
> import javax.security.auth.Subject;
> import javax.security.auth.login.LoginContext;
> import javax.security.auth.login.LoginException;
> import javax.security.auth.login.CredentialNotFoundException;
> import javax.resource.spi.security.PasswordCredential;
> import org.jboss.jms.server.bridge.BridgeService;
> public class JAASAwareBridgeService extends BridgeService {
>         private String sourceContext, targetContext;
>         public void setSourceLoginContext(String ctxName) { this.sourceContext = ctxName; }
>         public String getSourceLoginContext() { return this.sourceContext; }
>         public void setTargetLoginContext(String ctxName) { this.targetContext = ctxName; }
>         public String getTargetLoginContext() { return this.targetContext; }
>         public void start() throws Exception {
>                 setupSourceCredentials();
>                 setupTargetCredentials();
>                 super.start();
>         }
>         private void setupSourceCredentials() throws LoginException {
>                 PasswordCredential pc = getPasswordCredential(this.sourceContext);
>                 super.setSourceUsername(pc.getUserName());
>                 super.setSourcePassword(new String(pc.getPassword()));
>          }
>         private void setupTargetCredentials() throws LoginException {
>                 PasswordCredential pc = getPasswordCredential(this.targetContext);
>                 super.setTargetUsername(pc.getUserName());
>                 super.setTargetPassword(new String(pc.getPassword()));
>         }
>         private static PasswordCredential getPasswordCredential(String contextName) throws LoginException {
>                 LoginContext ctx = new LoginContext(contextName);
>                 ctx.login();
>                 Subject s = ctx.getSubject();
>                 Set<PasswordCredential> creds = s.getPrivateCredentials(PasswordCredential.class);
>                 if (creds.isEmpty())
>                         throw new CredentialNotFoundException("Login context '" + contextName + "' subject has no PasswordCredential");
>                 return creds.iterator().next(); // get 1st
>         }
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 03:13:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 03:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1478) inconsistent
 test suite performance
In-Reply-To: <25748306.1231170954442.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1896648838.1247642009415.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1478:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09


> inconsistent test suite performance
> -----------------------------------
>
>                 Key: JBMESSAGING-1478
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1478
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Tests and Performance
>    Affects Versions:  1.4.0.SP3.CP04
>            Reporter: Aleksandar Kostadinov
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09
>
>
> I see inconsistent performance running the JBM test suite. Here I have 2 builds on the same physical machine (windows), using local disk storage so environment should be pretty stable.
> The mysql database is shared but I doubt it is the culprit. 
> I run the test suite with the following options:
> property( name: "functional.tests.database", value: dbname )
> property( name: "stress.tests.database", value: dbname )
> property( name: "clustering.tests.database", value: dbname )
> property( name: "test.target", value: "report" )
> property( name: "test.bind.address", value: properties["env.MYTESTIP_1"] )
> property( name: "jboss.messaging.groupname", value: properties["env.BUILD_TAG"])                                                                               
> property( name: "jboss.messaging.datachanneludpaddress", value: properties["env.MCAST_ADDR"] )
> property( name: "jboss.messaging.controlchanneludpaddress", value: properties["env.MCAST_ADDR"] )
> Are there any other options I can add to increase isolation from other processes in the same LAN?
> Would you be able to look at these 2 builds and based on the logs, say why is the first one taking longer and eventually timeout?
> http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/163/
> http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/164/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 03:30:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 15 Jul 2009 03:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-359) Events attached to
	activities
Message-ID: <1291966959.1247643029123.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Events attached to activities 
------------------------------

                 Key: GPD-359
                 URL: https://jira.jboss.org/jira/browse/GPD-359
             Project: JBoss jBPM GPD
          Issue Type: Feature Request
            Reporter: Koen Aers
            Assignee: Koen Aers
             Fix For: jBPM jPDL Designer 4.x




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 04:08:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Wed, 15 Jul 2009 04:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-360) Refine wire object
	configuration
Message-ID: <1475697551.1247645309386.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Refine wire object configuration
--------------------------------

                 Key: GPD-360
                 URL: https://jira.jboss.org/jira/browse/GPD-360
             Project: JBoss jBPM GPD
          Issue Type: Feature Request
            Reporter: Koen Aers
            Assignee: Koen Aers
             Fix For: jBPM jPDL Designer 4.x




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 05:06:29 2009
From: jira-events at lists.jboss.org (Jaroslaw Kijanowski (JIRA))
Date: Wed, 15 Jul 2009 05:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2208) Agenda-group not
 picked up in decision table
Message-ID: <696057078.1247648789217.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Agenda-group not picked up in decision table
--------------------------------------------

                 Key: JBRULES-2208
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2208
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-decisiontables
    Affects Versions: 5.0.1.FINAL
            Reporter: Jaroslaw Kijanowski
            Assignee: Michael Neale


The class drools-decisiontables/src/main/java/org/drools/decisiontable/parser/DefaultRuleSheetListener
is missing AGENDAGROUP in the nextDataCell method.

Attaching patch.

This test class
drools-decisiontables/src/test/java/org/drools/decisiontable/parser/ActionTypeTest.java
could be also extended to verify the AGENDAGROUP keyword.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 05:08:29 2009
From: jira-events at lists.jboss.org (Jaroslaw Kijanowski (JIRA))
Date: Wed, 15 Jul 2009 05:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2208) Agenda-group not
 picked up in decision table
In-Reply-To: <696057078.1247648789217.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <367430244.1247648909226.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jaroslaw Kijanowski updated JBRULES-2208:
-----------------------------------------

    Attachment: patch


> Agenda-group not picked up in decision table
> --------------------------------------------
>
>                 Key: JBRULES-2208
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2208
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-decisiontables
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Jaroslaw Kijanowski
>            Assignee: Michael Neale
>         Attachments: patch
>
>
> The class drools-decisiontables/src/main/java/org/drools/decisiontable/parser/DefaultRuleSheetListener
> is missing AGENDAGROUP in the nextDataCell method.
> Attaching patch.
> This test class
> drools-decisiontables/src/test/java/org/drools/decisiontable/parser/ActionTypeTest.java
> could be also extended to verify the AGENDAGROUP keyword.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 05:29:41 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 15 Jul 2009 05:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1852) ejb-jar.xml
 <interceptor-order> not supported
In-Reply-To: <24247602.1245349076474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <748360419.1247650181023.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved EJBTHREE-1852.
-------------------------------------

    Resolution: Done


See JBPAPP-2262

> ejb-jar.xml <interceptor-order> not supported
> ---------------------------------------------
>
>                 Key: EJBTHREE-1852
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1852
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.5
>            Reporter: John Gilbert
>            Assignee: Carlo de Wolf
>             Fix For: 1.1.8
>
>
> The following exception is thrown when using <interceptor-order> in an ejb-jar.xml.
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialiseDefaultInterceptors(InterceptorInfoRepository.java:433)
>         at org.jboss.ejb3.interceptor.InterceptorInfoRepository.initialise(InterceptorInfoRepository.java:115)
>         at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:48)
>         at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
>         at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:611)
>         at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
>         at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>             <interceptor-order>
>          	<interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>          	<interceptor-class>my.CustomInterceptor</interceptor-class>
>             </interceptor-order>
>       </interceptor-binding>
>    </assembly-descriptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 05:29:40 2009
From: jira-events at lists.jboss.org (Bernard de Terwangne (JIRA))
Date: Wed, 15 Jul 2009 05:29:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2356) It is
 impossible to use html forms in portlets or js to build http request
In-Reply-To: <10202950.1238084123266.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <618037085.1247650180775.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476342#action_12476342 ] 

Bernard de Terwangne commented on JBPORTAL-2356:
------------------------------------------------

Thomas,

I'm getting back to you on this issue. My client just does want a full portal and prefers a simple portlet container. For now I'm providing JBPC with the attached fix. I see that the fix is not included in JBPC source code neither on the trunk or in tag 2.0.7. Can I have some hope that it would be included in a future version ?

On the other hand the comment in ControllerRequestFactory.java states that : 

/**
 * A factory that provides a way to create ControllerRequest. This factory is just a default implementation and is not
 * an authority which means that any client of the controller framework is free to determine how a controller request is
 * created.
 *
 * @author <a href="mailto:julien at jboss.org">Julien Viet</a>
 * @version $Revision: 630 $
 */

This is true only if you assume that my client provided implementation of the factory has the same fully qualified name. Indeed is instanciated in several places in the source code (ControllerFilter, PortalServlet, TCKServlet) always this way :

ControllerRequestFactory factory = new ControllerRequestFactory(context.getPageNavigationalStateSerialization());

So the only method for providing an alternative application as suggested by Julien Viet in its comment is to replace the class file. No possible configuration of the class name is provided or so. This is why it would be great to have my fix incorporated in a future version.

Bernard

> It is impossible to use html forms in portlets or js to build http request
> --------------------------------------------------------------------------
>
>                 Key: JBPORTAL-2356
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2356
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: Portlet-2.0.1
>         Environment: Linux, Java 5, Tomcat, JBoss Portlet Container 2.0
>            Reporter: Bernard de Terwangne
>         Attachments: ControllerRequestFactory.java, ControllerRequestFactory.java, ControllerRequestFactoryTestCase.java
>
>
> JBoss Portlet container conforms to the spec so well that it becomes unusable. It is impossible to query the end-user for a value and pass that value in processAction or serveResource calls. Let's say you write this in your JSP page :
> <form action="<portlet:actionURL><portlet:param name='q' value='yop'/></portlet:actionURL">
> <input name="q" type="text/>
> <input type="submit"/>
> </form>
> and in the Java code
> 	public void processAction(ActionRequest req, ActionResponse res)
> 			throws IOException, PortletException {
> 		System.out.println(req.getParameter("q");
>         }
> The printed value will allways be "yop" (the value placed in the portlet:param tag. There is no way to retrieve the value actually typed by the end user.
> This is due to the fact JBoss Portlet container mangles in Base64 the parameters from <portlet:param> and disregards parameters appended by the browser's form implementation. Same thing with <resourceURL>. There is no way to pass user input to the portlet's Java code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 06:39:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Wed, 15 Jul 2009 06:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7032) Getting invalid
 deployment on what appears to be valid, a webbeans ear file.
Message-ID: <829376347.1247654369258.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476353#action_12476353 ] 

Ales Justin commented on JBAS-7032:
-----------------------------------

>> I have found that an EAR which includes SEAM/RF library jars in the EAR/lib directory *without* a jboss-app.xml 

With any Seam app proper isolation *must* always be enforced,
otherwise Seam cannot work properly as its architecture depends on cl isolation.
e.g. Component::getComponent(name), static usage to get component from anywhere

WebBeans used to work the same way, but this prevented to be properly used inside OSGi based kernel/container.
Hence a different approach was used, scope/components per classloader hidden in a proper abstraction.

> Getting invalid deployment on what appears to be valid, a webbeans ear file.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7032
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7032
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>         Environment: JBoss AS 5.1
> JDK 1.6 u 13
> OpenSuSe 11.1 / SLES 10.2
>            Reporter: John Ament
>            Assignee: Shelly McGowan
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: jboss-app.xml, PrintResourcePathContextListener.class, PrintResourcePathContextListener.java, WhatUpDawg.ear, WhatUpDawg.ear
>
>
> The best description I can give is from the forum.
> Basically, I have an EAR that appears to be completely valid, it's 2 war's and 1 ejb module.  It's built using web beans.  I get the described stack trace when either deploying via the UI or just dropping the EAR file in deploy.  However, I get different results.  When I drop the ear in and restart, it loads perfectly (my app) but embedded jopr fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 07:15:29 2009
From: jira-events at lists.jboss.org (Vicky Kak (JIRA))
Date: Wed, 15 Jul 2009 07:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
In-Reply-To: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1260277230.1247656529612.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476360#action_12476360 ] 

Vicky Kak commented on JBAS-7086:
---------------------------------

I did perform some simple tests but did not get the 
************************************************************************
<%@ page import="javax.naming.*, javax.sql.*, javax.transaction.*,java.sql.*" %>
<%
   InitialContext context = new InitialContext();
   UserTransaction utx = (UserTransaction)context.lookup("UserTransaction");
   utx.begin();
   out.println("Started Transaction <br>");
   DataSource ds = (DataSource)context.lookup("OraDSXA");
   Connection con = ds.getConnection();
   out.println("Enlisted first Connection in TX <br>");
   Statement stmt = con.createStatement();
   out.println("Executing SQL :::: <br>");
   ResultSet rs = stmt.executeQuery("select * from tab");
   while(rs.next())
   out.println(rs.getString(1)+"<br>");
   out.println("Executing SQL Done :::: <br>");

   DataSource ds1 = (DataSource)context.lookup("OraGCDDSXA");
   Connection con1 = ds1.getConnection();
   out.println("Enlisted second Connection in TX <br>");
   Statement stmt1 = con1.createStatement();
   out.println("Executing SQL :::: <br>");
   ResultSet rs1 = stmt1.executeQuery("select * from tab");
   while(rs1.next())
   out.println(rs1.getString(1)+"<br>");
   out.println("Executing SQL Done:::: <br>");
   con1.close();

   con.close();
   utx.commit();
   out.println("Trasaction Completed !!!! <br>");

%>
************************************************************************

The -ds.xml content goes here
************************************************************************
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<xa-datasource>
     <jndi-name>OraDSXA</jndi-name>
     <use-java-context>false</use-java-context>
       <set-tx-query-timeout/>
     <track-connection-by-tx/>
     <isSameRM-override-value>false</isSameRM-override-value>
     <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
     <xa-datasource-property name="URL">jdbc:oracle:thin:@localhost:1521</xa-datasource-property>
     <xa-datasource-property name="User">scott</xa-datasource-property>
     <xa-datasource-property name="Password">tiger</xa-datasource-property>
     <!-- xa-datasource-property name="URL">jdbc:oracle:thin:@kevbates.sebtown.com:1522:SONATADB</xa-datasource-property>
     <xa-datasource-property name="User">OS1</xa-datasource-property>
     <xa-datasource-property name="Password">os1</xa-datasource-property -->
     <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
     <no-tx-separate-pools/>
     <metadata>
     <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
         <type-mapping>Oracle9i</type-mapping>
     </metadata>
 </xa-datasource>
</datasources>

<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<xa-datasource>
     <jndi-name>OraGCDDSXA</jndi-name>
     <use-java-context>false</use-java-context>
       <set-tx-query-timeout/>
     <track-connection-by-tx/>
     <isSameRM-override-value>false</isSameRM-override-value>
     <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
     <xa-datasource-property name="URL">jdbc:oracle:thin:@localhost:1521</xa-datasource-property>
     <xa-datasource-property name="User">scott</xa-datasource-property>
     <xa-datasource-property name="Password">tiger</xa-datasource-property>
     <!-- xa-datasource-property name="URL">jdbc:oracle:thin:@kevbates.sebtown.com:1522:SONATADB</xa-datasource-property>
     <xa-datasource-property name="User">GCD</xa-datasource-property>
     <xa-datasource-property name="Password">gcd</xa-datasource-property -->
     <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
     <no-tx-separate-pools/>
     <metadata>
     <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
         <type-mapping>Oracle9i</type-mapping>
     </metadata>
 </xa-datasource>
</datasources>
************************************************************************

I did test it on jboss-4.2.1.GA and on Jboss5.0.1 GA, the jsp works fine when I execute it in the Jboss4.* and it fails with following error in Jboss5
************************************************************************
15:48:25,785 WARN  [loggerI18N] [com.arjuna.ats.internal.jta.transaction.arjunacore.xastart] [com.arjuna.ats.internal.jta.transaction.arjunacore.xastart] TransactionImple.enlistResource - xa_start  - caught: XAException.XA_RETRY for < 131075, 27, 25, 494555102484848484849585756101495852975399539850505854505510248484848484958575610149585297539953985050585452 >
************************************************************************ 

> Can't enlist in transaction with second Oracle XA connection/resource.
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7086
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager (Arjuna)
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: The operating system has been windows, but that doesn't appear to be related.
> Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
>            Reporter: Kevin Bates
>            Assignee: Jesper Pedersen
>
> We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.
> At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:
> 2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
> oracle.jdbc.xa.OracleXAException
> 	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
> 	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
> 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
> com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
> 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
> 	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
> 	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
> 	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:404)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy134.executeChanges(Unknown Source)
> 	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:378)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy135.executeChanges(Unknown Source)
> 	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
> 	at java.security.AccessController.doPrivileged(AccessController.java:284)
> 	at javax.security.auth.Subject.doAs(Subject.java:573)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
> 	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
> 	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:735)
> Caused by: 
> org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
> 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 	... 90 more
> Caused by: 
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 	... 92 more
> Caused by: 
> javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	... 96 more
> The two XA data sources are configured as follows:
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">OS1</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraGCDDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">GCD</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.
> Kind regards.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 07:30:42 2009
From: jira-events at lists.jboss.org (Dmitri Voronov (JIRA))
Date: Wed, 15 Jul 2009 07:30:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
In-Reply-To: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <567590353.1247657442127.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476362#action_12476362 ] 

Dmitri Voronov commented on JBAS-7086:
--------------------------------------

I have the same problem with JBoss EAP 5.0 Alpha and Oracle 9. But with the version AS 5.1.0.GA the same case works fine.

> Can't enlist in transaction with second Oracle XA connection/resource.
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7086
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager (Arjuna)
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: The operating system has been windows, but that doesn't appear to be related.
> Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
>            Reporter: Kevin Bates
>            Assignee: Jesper Pedersen
>
> We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.
> At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:
> 2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
> oracle.jdbc.xa.OracleXAException
> 	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
> 	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
> 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
> com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
> 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
> 	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
> 	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
> 	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:404)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy134.executeChanges(Unknown Source)
> 	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:378)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy135.executeChanges(Unknown Source)
> 	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
> 	at java.security.AccessController.doPrivileged(AccessController.java:284)
> 	at javax.security.auth.Subject.doAs(Subject.java:573)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
> 	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
> 	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:735)
> Caused by: 
> org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
> 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 	... 90 more
> Caused by: 
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 	... 92 more
> Caused by: 
> javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	... 96 more
> The two XA data sources are configured as follows:
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">OS1</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraGCDDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">GCD</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.
> Kind regards.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 07:43:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Wed, 15 Jul 2009 07:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7097) Stack overflow
 error when establishing secured connection to Profile Service
Message-ID: <503635007.1247658209433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476363#action_12476363 ] 

Lukas Krejci commented on JBAS-7097:
------------------------------------

I've updated the ejb-client to try and replicate it (Jopr rev910) but everything seems to work correctly with JBPAPP_5_0 revision 91282. The JON server seems to connect OK now as well.

> Stack overflow error when establishing secured connection to Profile Service
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7097
>             Project: JBoss Application Server
>          Issue Type: Bug
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Jopr rev902, AS5 EAP rev91190
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The stack overflow occurs in Jopr AS5 plugin AbstractProfileServiceConnection.init() after the connection has been established.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
>         at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
> Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
>         at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
>         at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
>         ... 12 more                                                                                                                                                                       
> Caused by: java.lang.StackOverflowError                                                                                                                                                   
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
> ....                                                                           
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
>         ... 18 more                                                                                                                                                                       

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 08:03:47 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 15 Jul 2009 08:03:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1505) Optimise
 multiple message selectors on a queue
In-Reply-To: <5128840.1234454804372.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <263700000.1247659427720.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1505.
------------------------------------

    Resolution: Done


fixed in the trunk

> Optimise multiple message selectors on a queue
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1505
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1505
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> In the case where there are multiple message selectors on a queue, the entire queue needs to be scanned for each delivery.
> We can optimise this by adding indexes on the queue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 08:05:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 15 Jul 2009 08:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1533) Use boolean
 flag for enable grouping on distributor
In-Reply-To: <19593928.1236102863103.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <780355931.1247659529192.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1533.
------------------------------------

    Resolution: Out of Date


with JBMESSAGING-1505: grouping no longer needs to be configured by setting a special Distributor implementation

> Use boolean flag for enable grouping on distributor
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1533
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1533
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Right need to specify classname when enabling grouping on distributor - this should be a boolean flag

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 08:08:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 15 Jul 2009 08:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1673) MBean
 operations which
 requires a filter should treat an empty string as a null filter
In-Reply-To: <9927505.1246276136505.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1579169149.1247659709278.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1673.
------------------------------------

    Resolution: Done


fixed in the trunk

> MBean operations which requires a filter should treat an empty string as a null filter
> --------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1673
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1673
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 2.0.0.beta3
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> e.g. listMessages requires a filter parameter.
> Currently if an empty string is passed, it'll raise an exception when a filter is created from this string.
> Instead the MBean should check if the parameter is null or an empty string and treat it as a null filter.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 08:31:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 15 Jul 2009 08:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1616) Classpath
 issue with file version.properties
In-Reply-To: <7671035.1241530427144.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <956324910.1247661089219.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1616.
------------------------------------

    Resolution: Done


fixed in the trunk by renaming version.properties to jboss-messaging-version.properties

> Classpath issue with file version.properties
> --------------------------------------------
>
>                 Key: JBMESSAGING-1616
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1616
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Alpha
>            Reporter: Markus Probst
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> In class org.jboss.messaging.util.VersionLoader the static method "load" throws a NumberFormatException while trying to read properties from file version.properties, if several files with this name are situated in current classpath and the "wrong" one is picked up:
> "
> java.lang.NumberFormatException: null
> at java.lang.Integer.parseInt(Integer.java:415)
> at java.lang.Integer.valueOf(Integer.java:553)
> at org.jboss.messaging.util.VersionLoader.load(VersionLoader.java:50)
> at org.jboss.messaging.core.client.impl.ClientConnectionFactoryImpl.createConnection(ClientConnectionFactoryImpl.java:135)
> at org.jboss.messaging.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:255)
> at org.jboss.messaging.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:134)
> ...
> "
> It is very likely that more than one library/artifacts contains a file called "version.properties", so I think the right way should be to rename this file to a more JBoss Messaging specific one.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 09:33:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 15 Jul 2009 09:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1575) Add test for
 message size in selector and remove message id
In-Reply-To: <21091103.1239019103234.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <962012828.1247664809573.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1575.
------------------------------------

    Resolution: Done
      Assignee: Jeff Mesnil  (was: Tim Fox)


fixed in the trunk

> Add test for message size in selector and remove message id
> -----------------------------------------------------------
>
>                 Key: JBMESSAGING-1575
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1575
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> Add a selector test for message size, and remove message id from being used in selector expressions - it is not useful.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 10:29:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 15 Jul 2009 10:29:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBRULES-2202) Generated types
 should be Serializable
In-Reply-To: <1963762277.1247174669126.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1895821848.1247668169359.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reopened JBRULES-2202:
------------------------------------



MVELAccumulateFunctionExecutor still requires facts to be serializable. This should not be mandatory.

> Generated types should be Serializable
> --------------------------------------
>
>                 Key: JBRULES-2202
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2202
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler, drools-core
>    Affects Versions: 5.0.0.FINAL, 5.0.1.FINAL
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> Hello,
> Recently I've been working with Drools version 5.0.1 to set up an event processor.  While doing so I have come
> across difficulties with the accumulate function, in that it will always throw a ClassCastException
> when inserting events that are declared within my drl file.  To illustrate this I've set up an example which is
> shown below.  I've search Google and the mailing list for several hours, but the only way past this problem
> appears to be that I will have to declare a class externally and make sure it implements Serializable.  Does
> anyone has suggestions for another approach?  Secondly, I would have assumed that since Drools was
> compiling these internally declared classes, that Serializable would have been implemented automatically.  So
> is this a result of the generated class not implementing Serializable, or have I missed something in my rules
> file?  Thanks.
> The important part of my drl file is:
> declare TestEvent
>    @role( event )
>    @expires(10s)
>    id : String
> end
> #This rule works fine when 'Accumulate Count' is commented out, and is used to make
> #sure that the event inserting has worked.
> rule "Is It There"
>     when
>         TestEvent() from entry-point "test"
>     then
>         System.out.println("Found a TestEvent.");
> end
> #This rule throws a ClassCastException when a TestEvent is inserted.
> rule "Accumulate Count"
>     when
>         $n : Number() from accumulate($t : TestEvent() from entry-point "test",    count($t))
>     then
>         System.out.println("Found " + $n + " events.");
> end
> The unit test does this:
> FactType testEventType = session.getKnowledgeBase().getFactType("com.drools.test", "TestEvent");
> for(int i = 0; i < 10; i++){
>     Object testEvent = testEventType.newInstance();
>     testEventType.set(testEvent, "id", "id");
>     WorkingMemoryEntryPoint mainStream = session.getWorkingMemoryEntryPoint("test");
>     mainStream.insert(event);
>     session.fireAllRules();
> }
> The exception I receive is:
> org.drools.RuntimeDroolsException: java.lang.ClassCastException: com.drools.test.TestEvent cannot be cast to java.io.Serializable
>     at org.drools.rule.Accumulate.accumulate(Accumulate.java:172)
>     at org.drools.reteoo.AccumulateNode.modifyTuple(AccumulateNode.java:424)
>     at org.drools.reteoo.AccumulateNode.assertObject(AccumulateNode.java:284)
>     at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:42)
>     at org.drools.reteoo.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:326)
>     at org.drools.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:221)
>     at org.drools.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:394)
>     at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1486)
>     at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:158)
>     at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:122)
>     at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:80)
>     at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:28)
>     at com.drools.test.MyUnitTest.testEvents(EvaluationTest.java:66)
>     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.springframework.test.context.junit4.SpringTestMethod.invoke(SpringTestMethod.java:160)
>     at org.springframework.test.context.junit4.SpringMethodRoadie.runTestMethod(SpringMethodRoadie.java:233)
>     at org.springframework.test.context.junit4.SpringMethodRoadie$RunBeforesThenTestThenAfters.run(SpringMethodRoadie.java:333)
>     at org.springframework.test.context.junit4.SpringMethodRoadie.runWithRepetitions(SpringMethodRoadie.java:217)
>     at org.springframework.test.context.junit4.SpringMethodRoadie.runTest(SpringMethodRoadie.java:197)
>     at org.springframework.test.context.junit4.SpringMethodRoadie.run(SpringMethodRoadie.java:143)
>     at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.invokeTestMethod(SpringJUnit4ClassRunner.java:160)
>     at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
>     at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
>     at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
>     at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
>     at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
>     at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:97)
>     at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
>     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)
> Caused by: java.lang.ClassCastException: com.drools.test.TestEvent cannot be cast to java.io.Serializable
>     at org.drools.base.accumulators.JavaAccumulatorFunctionExecutor.accumulate(JavaAccumulatorFunctionExecutor.java:110)
>     at org.drools.rule.Accumulate.accumulate(Accumulate.java:164)
>     ... 36 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 10:37:42 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 15 Jul 2009 10:37:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-534) Maven repository
	aggregation
In-Reply-To: <1192295848.1247639309938.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1169163025.1247668662514.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476406#action_12476406 ] 

Paul Gier commented on JBBUILD-534:
-----------------------------------

This is currently dependent on jboss.org.  The issue for the past year has been that jboss.org doesn't have any space available for this.  I've talked to IT and Mark Newton about this and was told to wait until they have more servers available.

I'm currently looking into an alternative hosting solution, and will provide more info when it's available.

> Maven repository aggregation
> ----------------------------
>
>                 Key: JBBUILD-534
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-534
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Thomas Diesler
>
> There are a number of projects which have dependencies on non-jboss
> maven repos (jboss-osgi is one of them)
> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235779#4235779
> I believe, this issue is general enough to have proper repo aggregation 
> setup somehow
> Here is a link to some aggregators
> http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix
> Is this a way you want to move forward or should we stick with manually copying individual artefacts to the jboss repo? 
> Please note, that by doing so (i.e. mvn deploy-file) you loose the original pom and hence the information on transitive dependencies.
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 10:39:29 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Wed, 15 Jul 2009 10:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7099)
 java.lang.NullPointerException in VFSContextFactoryLocator
Message-ID: <1143733132.1247668769749.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

java.lang.NullPointerException in VFSContextFactoryLocator
----------------------------------------------------------

                 Key: JBAS-7099
                 URL: https://jira.jboss.org/jira/browse/JBAS-7099
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.1.0.GA
         Environment: 16:30:34,262 INFO  [ServerInfo] Java version: 1.6.0_14,Sun Microsystems Inc.
16:30:34,262 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
16:30:34,262 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 14.0-b16,Sun Microsystems Inc.
16:30:34,262 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
16:30:34,263 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 

            Reporter: Juergen none


16:30:46,263 INFO  [LogNotificationListener] Adding notification listener for logging mbean "jboss.system:service=Logging,type=Log4jService" to server org.jboss.mx.server.MBeanServerImpl at 14800aa1[ defaultDomain='jboss' ]
16:30:47,254 ERROR [ScopedProfileServiceController] Error installing to Create: name=ProfileKey at 7810a519[domain=default, server=default, name=applications] state=Configured mode=On Demand requiredState=Installed
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        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.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:97)
        at org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:77)
        at org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.install(AbstractProfileLifeCycleAction.java:49)
        at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
        at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
        at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
        at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
        at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
        at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
        at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
        at org.jboss.Main.boot(Main.java:221)
        at org.jboss.Main$1.run(Main.java:556)
        at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
        at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
        at org.jboss.virtual.spi.VFSContextFactoryLocator.getFactory(VFSContextFactoryLocator.java:187)
        at org.jboss.virtual.VFS.getVFS(VFS.java:166)
        at org.jboss.virtual.VFS.createNewRoot(VFS.java:185)
        at org.jboss.virtual.VFS.getRoot(VFS.java:201)
        at org.jboss.system.server.profileservice.repository.AbstractVFSProfileSource.getCachedVirtualFile(AbstractVFSProfileSource.java:353)
        at org.jboss.system.server.profileservice.repository.BasicDeploymentRepository.load(BasicDeploymentRepository.java:113)
        at org.jboss.system.server.profile.repository.AbstractProfile.create(AbstractProfile.java:158)
        ... 22 more
16:30:47,255 ERROR [STDERR] Failed to boot JBoss:
16:30:47,255 ERROR [STDERR] java.lang.IllegalStateException: Incompletely deployed:

*** PROFILES IN ERROR: Name -> Error
Profile: ProfileKey at 7810a519[domain=default, server=default, name=applications] in error due to java.lang.reflect.InvocationTargetException

*** PROFILES MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
ProfileKey at 3a7e479a[domain=default, server=default, name=campus] is missing following dependencies: ProfileKey at 7810a519[domain=default, server=default, name=applications]{Installed:**ERROR**}
16:30:47,255 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.logErrors(AbstractProfileService.java:567)
16:30:47,255 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.validate(AbstractProfileService.java:348)
16:30:47,256 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.validateProfile(AbstractProfileService.java:331)
16:30:47,256 ERROR [STDERR]     at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:272)
16:30:47,256 ERROR [STDERR]     at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
16:30:47,256 ERROR [STDERR]     at org.jboss.Main.boot(Main.java:221)
16:30:47,256 ERROR [STDERR]     at org.jboss.Main$1.run(Main.java:556)
16:30:47,256 ERROR [STDERR]     at java.lang.Thread.run(Thread.java:619)

stop server, switched to jdk 5: got UnsupportedClassVersionError

16:35:19,253 INFO  [ServerInfo] Java version: 1.5.0_15,Sun Microsystems Inc.
16:35:19,253 INFO  [ServerInfo] Java Runtime: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
16:35:19,253 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 1.5.0_15-b04,Sun Microsystems Inc.
16:35:19,253 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
16:35:19,254 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 


16:35:19,253 INFO  [ServerInfo] Java version: 1.5.0_15,Sun Microsystems Inc.
16:35:19,253 INFO  [ServerInfo] Java Runtime: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
16:35:19,253 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 1.5.0_15-b04,Sun Microsystems Inc.
16:35:19,253 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
16:35:19,254 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
16:35:19,302 INFO  [JMXKernel] Legacy JMX core initialized
16:35:21,956 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 31f9b804[domain=default, server=default, name=campus]
16:35:24,595 INFO  [WebService] Using RMI server codebase: http://127.0.0.1:8083/
16:35:26,916 WARN  [ClassLoaderManager] Unexpected error during load of:org.jboss.resource.metadata.repository.DefaultJCAMetaDataRepository
java.lang.UnsupportedClassVersionError: Bad version number in .class file
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
        at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
        at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
        at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)
        at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
        at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
        at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
        at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:251)
        at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:150)
        at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265)
        at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)
        at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)
        at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.addBeanComponent(BeanMetaDataFactoryVisitor.java:63)
        at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.deploy(BeanMetaDataFactoryVisitor.java:126)
        at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
        at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.internalDeploy(AbstractRealDeployerWithInput.java:102)
        at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:78)
        at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
        at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
        at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
        at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
        at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
        at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
        at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
        at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
        at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
        at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
        at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
        at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
        at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
        at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
        at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
        at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
        at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
        at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
        at org.jboss.Main.boot(Main.java:221)
        at org.jboss.Main$1.run(Main.java:556)
        at java.lang.Thread.run(Thread.java:595)
16:35:26,918 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/opt/jboss/jboss-5.1.0.GA/server/campus/deployers/jboss-jca.deployer/ state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: Error deploying: vfsfile:/opt/jboss/jboss-5.1.0.GA/server/campus/deployers/jboss-jca.deployer/


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 10:47:29 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Wed, 15 Jul 2009 10:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7099)
 java.lang.NullPointerException in VFSContextFactoryLocator
In-Reply-To: <1143733132.1247668769749.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <182439815.1247669249324.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476414#action_12476414 ] 

Juergen none commented on JBAS-7099:
------------------------------------

forget the second part with jdk 5, not completely sure that I didn't use jdk6 build...

> java.lang.NullPointerException in VFSContextFactoryLocator
> ----------------------------------------------------------
>
>                 Key: JBAS-7099
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7099
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: 16:30:34,262 INFO  [ServerInfo] Java version: 1.6.0_14,Sun Microsystems Inc.
> 16:30:34,262 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
> 16:30:34,262 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 14.0-b16,Sun Microsystems Inc.
> 16:30:34,262 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 16:30:34,263 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
>            Reporter: Juergen none
>
> 16:30:46,263 INFO  [LogNotificationListener] Adding notification listener for logging mbean "jboss.system:service=Logging,type=Log4jService" to server org.jboss.mx.server.MBeanServerImpl at 14800aa1[ defaultDomain='jboss' ]
> 16:30:47,254 ERROR [ScopedProfileServiceController] Error installing to Create: name=ProfileKey at 7810a519[domain=default, server=default, name=applications] state=Configured mode=On Demand requiredState=Installed
> java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:97)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:77)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.install(AbstractProfileLifeCycleAction.java:49)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
>         at org.jboss.Main.boot(Main.java:221)
>         at org.jboss.Main$1.run(Main.java:556)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NullPointerException
>         at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
>         at org.jboss.virtual.spi.VFSContextFactoryLocator.getFactory(VFSContextFactoryLocator.java:187)
>         at org.jboss.virtual.VFS.getVFS(VFS.java:166)
>         at org.jboss.virtual.VFS.createNewRoot(VFS.java:185)
>         at org.jboss.virtual.VFS.getRoot(VFS.java:201)
>         at org.jboss.system.server.profileservice.repository.AbstractVFSProfileSource.getCachedVirtualFile(AbstractVFSProfileSource.java:353)
>         at org.jboss.system.server.profileservice.repository.BasicDeploymentRepository.load(BasicDeploymentRepository.java:113)
>         at org.jboss.system.server.profile.repository.AbstractProfile.create(AbstractProfile.java:158)
>         ... 22 more
> 16:30:47,255 ERROR [STDERR] Failed to boot JBoss:
> 16:30:47,255 ERROR [STDERR] java.lang.IllegalStateException: Incompletely deployed:
> *** PROFILES IN ERROR: Name -> Error
> Profile: ProfileKey at 7810a519[domain=default, server=default, name=applications] in error due to java.lang.reflect.InvocationTargetException
> *** PROFILES MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> ProfileKey at 3a7e479a[domain=default, server=default, name=campus] is missing following dependencies: ProfileKey at 7810a519[domain=default, server=default, name=applications]{Installed:**ERROR**}
> 16:30:47,255 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.logErrors(AbstractProfileService.java:567)
> 16:30:47,255 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.validate(AbstractProfileService.java:348)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.validateProfile(AbstractProfileService.java:331)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:272)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.Main.boot(Main.java:221)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.Main$1.run(Main.java:556)
> 16:30:47,256 ERROR [STDERR]     at java.lang.Thread.run(Thread.java:619)
> stop server, switched to jdk 5: got UnsupportedClassVersionError
> 16:35:19,253 INFO  [ServerInfo] Java version: 1.5.0_15,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] Java Runtime: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
> 16:35:19,253 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 1.5.0_15-b04,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 16:35:19,254 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
> 16:35:19,253 INFO  [ServerInfo] Java version: 1.5.0_15,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] Java Runtime: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
> 16:35:19,253 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 1.5.0_15-b04,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 16:35:19,254 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
> 16:35:19,302 INFO  [JMXKernel] Legacy JMX core initialized
> 16:35:21,956 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 31f9b804[domain=default, server=default, name=campus]
> 16:35:24,595 INFO  [WebService] Using RMI server codebase: http://127.0.0.1:8083/
> 16:35:26,916 WARN  [ClassLoaderManager] Unexpected error during load of:org.jboss.resource.metadata.repository.DefaultJCAMetaDataRepository
> java.lang.UnsupportedClassVersionError: Bad version number in .class file
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
>         at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
>         at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
>         at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)
>         at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
>         at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
>         at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
>         at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:251)
>         at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:150)
>         at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265)
>         at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.addBeanComponent(BeanMetaDataFactoryVisitor.java:63)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.deploy(BeanMetaDataFactoryVisitor.java:126)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.internalDeploy(AbstractRealDeployerWithInput.java:102)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:78)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
>         at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
>         at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
>         at org.jboss.Main.boot(Main.java:221)
>         at org.jboss.Main$1.run(Main.java:556)
>         at java.lang.Thread.run(Thread.java:595)
> 16:35:26,918 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/opt/jboss/jboss-5.1.0.GA/server/campus/deployers/jboss-jca.deployer/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: vfsfile:/opt/jboss/jboss-5.1.0.GA/server/campus/deployers/jboss-jca.deployer/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 11:34:30 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Wed, 15 Jul 2009 11:34:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7099)
 java.lang.NullPointerException in VFSContextFactoryLocator
In-Reply-To: <1143733132.1247668769749.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <821104293.1247672070272.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476420#action_12476420 ] 

Juergen none commented on JBAS-7099:
------------------------------------

info: reason seem to be exploded war deployment
added to /conf/bootstrap/profile.xml:
			<list elementClass="java.net.URI">
				<value>${jboss.server.home.url}deploy</value>
<value>/path/to/deploy/dir/with/exploded/war</value>
			</list>

in directory: /path/to/deploy/dir/with/exploded/war
exists another directory: test.war


> java.lang.NullPointerException in VFSContextFactoryLocator
> ----------------------------------------------------------
>
>                 Key: JBAS-7099
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7099
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: 16:30:34,262 INFO  [ServerInfo] Java version: 1.6.0_14,Sun Microsystems Inc.
> 16:30:34,262 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
> 16:30:34,262 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 14.0-b16,Sun Microsystems Inc.
> 16:30:34,262 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 16:30:34,263 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
>            Reporter: Juergen none
>
> 16:30:46,263 INFO  [LogNotificationListener] Adding notification listener for logging mbean "jboss.system:service=Logging,type=Log4jService" to server org.jboss.mx.server.MBeanServerImpl at 14800aa1[ defaultDomain='jboss' ]
> 16:30:47,254 ERROR [ScopedProfileServiceController] Error installing to Create: name=ProfileKey at 7810a519[domain=default, server=default, name=applications] state=Configured mode=On Demand requiredState=Installed
> java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:97)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:77)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.install(AbstractProfileLifeCycleAction.java:49)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
>         at org.jboss.Main.boot(Main.java:221)
>         at org.jboss.Main$1.run(Main.java:556)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NullPointerException
>         at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
>         at org.jboss.virtual.spi.VFSContextFactoryLocator.getFactory(VFSContextFactoryLocator.java:187)
>         at org.jboss.virtual.VFS.getVFS(VFS.java:166)
>         at org.jboss.virtual.VFS.createNewRoot(VFS.java:185)
>         at org.jboss.virtual.VFS.getRoot(VFS.java:201)
>         at org.jboss.system.server.profileservice.repository.AbstractVFSProfileSource.getCachedVirtualFile(AbstractVFSProfileSource.java:353)
>         at org.jboss.system.server.profileservice.repository.BasicDeploymentRepository.load(BasicDeploymentRepository.java:113)
>         at org.jboss.system.server.profile.repository.AbstractProfile.create(AbstractProfile.java:158)
>         ... 22 more
> 16:30:47,255 ERROR [STDERR] Failed to boot JBoss:
> 16:30:47,255 ERROR [STDERR] java.lang.IllegalStateException: Incompletely deployed:
> *** PROFILES IN ERROR: Name -> Error
> Profile: ProfileKey at 7810a519[domain=default, server=default, name=applications] in error due to java.lang.reflect.InvocationTargetException
> *** PROFILES MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> ProfileKey at 3a7e479a[domain=default, server=default, name=campus] is missing following dependencies: ProfileKey at 7810a519[domain=default, server=default, name=applications]{Installed:**ERROR**}
> 16:30:47,255 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.logErrors(AbstractProfileService.java:567)
> 16:30:47,255 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.validate(AbstractProfileService.java:348)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.validateProfile(AbstractProfileService.java:331)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:272)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.Main.boot(Main.java:221)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.Main$1.run(Main.java:556)
> 16:30:47,256 ERROR [STDERR]     at java.lang.Thread.run(Thread.java:619)
> stop server, switched to jdk 5: got UnsupportedClassVersionError
> 16:35:19,253 INFO  [ServerInfo] Java version: 1.5.0_15,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] Java Runtime: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
> 16:35:19,253 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 1.5.0_15-b04,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 16:35:19,254 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
> 16:35:19,253 INFO  [ServerInfo] Java version: 1.5.0_15,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] Java Runtime: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
> 16:35:19,253 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 1.5.0_15-b04,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 16:35:19,254 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
> 16:35:19,302 INFO  [JMXKernel] Legacy JMX core initialized
> 16:35:21,956 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 31f9b804[domain=default, server=default, name=campus]
> 16:35:24,595 INFO  [WebService] Using RMI server codebase: http://127.0.0.1:8083/
> 16:35:26,916 WARN  [ClassLoaderManager] Unexpected error during load of:org.jboss.resource.metadata.repository.DefaultJCAMetaDataRepository
> java.lang.UnsupportedClassVersionError: Bad version number in .class file
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
>         at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
>         at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
>         at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)
>         at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
>         at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
>         at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
>         at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:251)
>         at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:150)
>         at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265)
>         at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.addBeanComponent(BeanMetaDataFactoryVisitor.java:63)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.deploy(BeanMetaDataFactoryVisitor.java:126)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.internalDeploy(AbstractRealDeployerWithInput.java:102)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:78)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
>         at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
>         at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
>         at org.jboss.Main.boot(Main.java:221)
>         at org.jboss.Main$1.run(Main.java:556)
>         at java.lang.Thread.run(Thread.java:595)
> 16:35:26,918 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/opt/jboss/jboss-5.1.0.GA/server/campus/deployers/jboss-jca.deployer/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: vfsfile:/opt/jboss/jboss-5.1.0.GA/server/campus/deployers/jboss-jca.deployer/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 11:43:41 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Wed, 15 Jul 2009 11:43:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7099)
 java.lang.NullPointerException in VFSContextFactoryLocator
In-Reply-To: <1143733132.1247668769749.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <581272256.1247672621231.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476423#action_12476423 ] 

Juergen none commented on JBAS-7099:
------------------------------------

ok, reason:
did not add file:// protocol to <value>

worked with
<value>file://path/to/deploy/dir/with/exploded/war</value>

Still, pretty insensible of jboss to react with a NullPointerException

> java.lang.NullPointerException in VFSContextFactoryLocator
> ----------------------------------------------------------
>
>                 Key: JBAS-7099
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7099
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: 16:30:34,262 INFO  [ServerInfo] Java version: 1.6.0_14,Sun Microsystems Inc.
> 16:30:34,262 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
> 16:30:34,262 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 14.0-b16,Sun Microsystems Inc.
> 16:30:34,262 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 16:30:34,263 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
>            Reporter: Juergen none
>
> 16:30:46,263 INFO  [LogNotificationListener] Adding notification listener for logging mbean "jboss.system:service=Logging,type=Log4jService" to server org.jboss.mx.server.MBeanServerImpl at 14800aa1[ defaultDomain='jboss' ]
> 16:30:47,254 ERROR [ScopedProfileServiceController] Error installing to Create: name=ProfileKey at 7810a519[domain=default, server=default, name=applications] state=Configured mode=On Demand requiredState=Installed
> java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:97)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:77)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.install(AbstractProfileLifeCycleAction.java:49)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
>         at org.jboss.Main.boot(Main.java:221)
>         at org.jboss.Main$1.run(Main.java:556)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NullPointerException
>         at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
>         at org.jboss.virtual.spi.VFSContextFactoryLocator.getFactory(VFSContextFactoryLocator.java:187)
>         at org.jboss.virtual.VFS.getVFS(VFS.java:166)
>         at org.jboss.virtual.VFS.createNewRoot(VFS.java:185)
>         at org.jboss.virtual.VFS.getRoot(VFS.java:201)
>         at org.jboss.system.server.profileservice.repository.AbstractVFSProfileSource.getCachedVirtualFile(AbstractVFSProfileSource.java:353)
>         at org.jboss.system.server.profileservice.repository.BasicDeploymentRepository.load(BasicDeploymentRepository.java:113)
>         at org.jboss.system.server.profile.repository.AbstractProfile.create(AbstractProfile.java:158)
>         ... 22 more
> 16:30:47,255 ERROR [STDERR] Failed to boot JBoss:
> 16:30:47,255 ERROR [STDERR] java.lang.IllegalStateException: Incompletely deployed:
> *** PROFILES IN ERROR: Name -> Error
> Profile: ProfileKey at 7810a519[domain=default, server=default, name=applications] in error due to java.lang.reflect.InvocationTargetException
> *** PROFILES MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
> ProfileKey at 3a7e479a[domain=default, server=default, name=campus] is missing following dependencies: ProfileKey at 7810a519[domain=default, server=default, name=applications]{Installed:**ERROR**}
> 16:30:47,255 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.logErrors(AbstractProfileService.java:567)
> 16:30:47,255 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.validate(AbstractProfileService.java:348)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.system.server.profileservice.repository.AbstractProfileService.validateProfile(AbstractProfileService.java:331)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:272)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.Main.boot(Main.java:221)
> 16:30:47,256 ERROR [STDERR]     at org.jboss.Main$1.run(Main.java:556)
> 16:30:47,256 ERROR [STDERR]     at java.lang.Thread.run(Thread.java:619)
> stop server, switched to jdk 5: got UnsupportedClassVersionError
> 16:35:19,253 INFO  [ServerInfo] Java version: 1.5.0_15,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] Java Runtime: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
> 16:35:19,253 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 1.5.0_15-b04,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 16:35:19,254 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
> 16:35:19,253 INFO  [ServerInfo] Java version: 1.5.0_15,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] Java Runtime: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
> 16:35:19,253 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 1.5.0_15-b04,Sun Microsystems Inc.
> 16:35:19,253 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 16:35:19,254 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
> 16:35:19,302 INFO  [JMXKernel] Legacy JMX core initialized
> 16:35:21,956 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 31f9b804[domain=default, server=default, name=campus]
> 16:35:24,595 INFO  [WebService] Using RMI server codebase: http://127.0.0.1:8083/
> 16:35:26,916 WARN  [ClassLoaderManager] Unexpected error during load of:org.jboss.resource.metadata.repository.DefaultJCAMetaDataRepository
> java.lang.UnsupportedClassVersionError: Bad version number in .class file
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
>         at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
>         at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
>         at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)
>         at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
>         at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
>         at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
>         at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:251)
>         at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:150)
>         at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265)
>         at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.addBeanComponent(BeanMetaDataFactoryVisitor.java:63)
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.deploy(BeanMetaDataFactoryVisitor.java:126)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.internalDeploy(AbstractRealDeployerWithInput.java:102)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:78)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
>         at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
>         at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
>         at org.jboss.Main.boot(Main.java:221)
>         at org.jboss.Main$1.run(Main.java:556)
>         at java.lang.Thread.run(Thread.java:595)
> 16:35:26,918 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/opt/jboss/jboss-5.1.0.GA/server/campus/deployers/jboss-jca.deployer/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: vfsfile:/opt/jboss/jboss-5.1.0.GA/server/campus/deployers/jboss-jca.deployer/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From tbenning at redhat.com  Fri Jul 17 13:53:57 2009
From: tbenning at redhat.com (Tom Benninger)
Date: Fri, 17 Jul 2009 13:53:57 -0400
Subject: [jboss-jira] Testing List
Message-ID: <4A60BAB5.8020708@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Testing List Archive

Tom Benninger
Red Hat System Engineer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpgurUACgkQa864S3iPzuLzxACg8AgJcbAnweu2LbAw7gRh/bjK
rZMAnjKpNBEofbdQjuAqM++m8uWCnxrP
=V71G
-----END PGP SIGNATURE-----


From david.lloyd at redhat.com  Fri Jul 17 14:07:50 2009
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 17 Jul 2009 13:07:50 -0500
Subject: [jboss-jira] Testing List
In-Reply-To: <4A60BAB5.8020708@redhat.com>
References: <4A60BAB5.8020708@redhat.com>
Message-ID: <4A60BDF6.9030601@redhat.com>

Got it!

On 07/17/2009 12:53 PM, Tom Benninger wrote:
> Testing List Archive
> 
> Tom Benninger
> Red Hat System Engineer
_______________________________________________
jboss-jira mailing list
jboss-jira at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-jira


From postmaster at lists.jboss.org  Sun Jul 19 14:04:13 2009
From: postmaster at lists.jboss.org (Bounced mail)
Date: Sun, 19 Jul 2009 14:04:13 -0400
Subject: [jboss-jira] Returned mail: Data format error
Message-ID: <200907191804.n6JI4CTD009810@lists01.dmz-a.mwc.hst.phx2.redhat.com>

Dear user of lists.jboss.org,

Your e-mail account was used to send a huge amount of spam messages during this week.
Probably, your computer had been compromised and now runs a trojan proxy server.

We recommend you to follow the instruction in order to keep your computer safe.

Have a nice day,
The lists.jboss.org support team.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: document.zip
Type: application/octet-stream
Size: 28986 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jboss-jira/attachments/20090719/46340fb7/attachment-0002.obj 

From jira-events at lists.jboss.org  Mon Jul 20 14:32:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 14:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1871) Add generics to
 InvocationStatistics
Message-ID: <2059326149.1248114749971.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add generics to InvocationStatistics
------------------------------------

                 Key: EJBTHREE-1871
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1871
             Project: EJB 3.0
          Issue Type: Feature Request
          Components: core
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 1.1.10


Lack of generics (and wrong documentation regarding the runtime types) have lead to JBAS-7108.  Apply generics to the backing method maps.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 14:34:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 14:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1871) Add generics to
 InvocationStatistics
In-Reply-To: <2059326149.1248114749971.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1968860877.1248114869757.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved EJBTHREE-1871.
-------------------------------------------

    Resolution: Done


> Add generics to InvocationStatistics
> ------------------------------------
>
>                 Key: EJBTHREE-1871
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1871
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: core
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.10
>
>
> Lack of generics (and wrong documentation regarding the runtime types) have lead to JBAS-7108.  Apply generics to the backing method maps.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 14:23:29 2009
From: jira-events at lists.jboss.org (Robert Dale (JIRA))
Date: Mon, 20 Jul 2009 14:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7068) Wrong
 timeout-valiue in OracleValidConnectionChecker
In-Reply-To: <699957358.1246433863204.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1121858199.1248114209321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476901#action_12476901 ] 

Robert Dale commented on JBAS-7068:
-----------------------------------

up until 10.2.0.5 and 11g drivers, this timeout was ignored.  However, now the timeout is accepted (and for some reason the method has been deprecated).  The code does Thread.join(timeout * 1000).

> Wrong timeout-valiue in OracleValidConnectionChecker
> ----------------------------------------------------
>
>                 Key: JBAS-7068
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7068
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Christian Daszenies
>            Assignee: Jesper Pedersen
>
> OracleValidConnectionChecker calls 
> oracle.jdbc.driver.OracleConnection.pingDatabase(5000) - 5000 is used as timeout in seconds! by pingDatabase
> furthermore it would be nice if the timeout would be configurable (or at least easy to override)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 12:14:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jul 2009 12:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1015) Unit tests: enable
 "gossip-router" tests
Message-ID: <340503133.1248106469270.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Unit tests: enable "gossip-router" tests
----------------------------------------

                 Key: JGRP-1015
                 URL: https://jira.jboss.org/jira/browse/JGRP-1015
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Minor
             Fix For: 2.8


Currently not run with TestNG

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 11:50:29 2009
From: jira-events at lists.jboss.org (Christopher Mason (JIRA))
Date: Mon, 20 Jul 2009 11:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2434) Section 20.3.3.2
 LDAPExtRoleModuleImpl incorrectly states default searchScope of
 SUBTREE_SCOPE
Message-ID: <95815187.1248105029544.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Section 20.3.3.2 LDAPExtRoleModuleImpl incorrectly states default searchScope of SUBTREE_SCOPE
----------------------------------------------------------------------------------------------

                 Key: JBPORTAL-2434
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2434
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Reference Guide
    Affects Versions: 2.7.1 Final
            Reporter: Christopher Mason


Reference Guide states that the default search scope for LDAPExtRoleModuleImpl is SUBTREE_SCOPE. However the default value returned by getSearchScope in LDAPRoleModule, which is used by LDAPExtRoleModuleImpl is ONELEVEL_SCOPE.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 12:26:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jul 2009 12:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1001) Use ByteMan /
 Metronome to inject faults for testing
In-Reply-To: <18204662.1245926771912.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <148635136.1248107189961.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1001:
---------------------------

    Fix Version/s: 2.9
                       (was: 2.8)


> Use ByteMan / Metronome to inject faults for testing
> ----------------------------------------------------
>
>                 Key: JGRP-1001
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1001
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.9
>
>
> Use ByteMan (jboss.org/byteman) to simulate issues that can happen at runtime: do this in unit tests.
> For example: crash of merge leader after initial round (who frees the locks ?) (same for FLUSH)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 12:26:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jul 2009 12:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1014) NAKACK: SET_DIGEST
 does not overwrite the digest
In-Reply-To: <299603632.1248080503568.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1980476570.1248107189666.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1014.
----------------------------

    Resolution: Done


> NAKACK: SET_DIGEST does not overwrite the digest
> ------------------------------------------------
>
>                 Key: JGRP-1014
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1014
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> When we set a digest in NAKACK, we do not overwrite an element for a member if it already exists. With state transfer, the following issue can occur (see [1]):
> Scenario #2:
> - [NAKACK] D receives B:11 (digest is 11 now for B)
> - [NAKACK] D applies the digest: this does NOT reset the digest for B to #10, but it remains #11 !!
> - D delivers B:11 to the app, changes state
> - D sets state, overwriting the change from B:11
> --> B:11 will NOT get retransmitted as the digest in NAKACK contains it !
> --> B:11 is lost
> SOLUTION: maybe add a 'state' boolean to the setDigest() method and overwrite if true
> This is a regression in 2.8 only; 2.6.x and 2.4.x handle SET_DIGEST correctly and do overwrite the digest.
> [1] https://jira.jboss.org/jira/browse/JGRP-1013

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 12:26:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jul 2009 12:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1014) NAKACK: SET_DIGEST
 does not overwrite the digest
In-Reply-To: <299603632.1248080503568.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2049652807.1248107189494.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476882#action_12476882 ] 

Bela Ban commented on JGRP-1014:
--------------------------------

STATE_TRANSFER and STREAMING_STATE_TRANSFER now use OVERWRITE_DIGEST instead of SET_DIGEST. So setting the digest to B:10 after the message B:11 set it to B:11 will reset the digest to B:10, therefore the B:11 message (whose state change was overwritten) will get retransmitted.

> NAKACK: SET_DIGEST does not overwrite the digest
> ------------------------------------------------
>
>                 Key: JGRP-1014
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1014
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> When we set a digest in NAKACK, we do not overwrite an element for a member if it already exists. With state transfer, the following issue can occur (see [1]):
> Scenario #2:
> - [NAKACK] D receives B:11 (digest is 11 now for B)
> - [NAKACK] D applies the digest: this does NOT reset the digest for B to #10, but it remains #11 !!
> - D delivers B:11 to the app, changes state
> - D sets state, overwriting the change from B:11
> --> B:11 will NOT get retransmitted as the digest in NAKACK contains it !
> --> B:11 is lost
> SOLUTION: maybe add a 'state' boolean to the setDigest() method and overwrite if true
> This is a regression in 2.8 only; 2.6.x and 2.4.x handle SET_DIGEST correctly and do overwrite the digest.
> [1] https://jira.jboss.org/jira/browse/JGRP-1013

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 12:26:29 2009
From: jira-events at lists.jboss.org (Philip Dodds (JIRA))
Date: Mon, 20 Jul 2009 12:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1870) stopDelivery on
 active MDB results in exception (Session not found)
In-Reply-To: <830057413.1248107189559.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <907686711.1248107189733.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Philip Dodds updated EJBTHREE-1870:
-----------------------------------

    Attachment: stopdelivery-mdb.zip


This is the doctored EJB3 MDB code that I used to recreate the problem.

> stopDelivery on active MDB results in exception (Session not found)
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1870
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1870
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: ejb3
>    Affects Versions: 1.1.3
>         Environment: Mac OS/X Leopard, JDK 6, JBoss 5.1.0GA
>            Reporter: Philip Dodds
>         Attachments: stopdelivery-mdb.zip
>
>
> If you start an MDB and introduce a messages to it then use the stopDelivery method of the MDB's MBean to stop it consuming messages you get an exception.  Note this problem only occurs if the MDB has a transaction in flight when the stopDelivery is called.
> 2009-05-20 12:30:52,499 ERROR [org.jboss.messaging.util.ExceptionUtil] (WorkManager(2)-44) Connectio
> nEndpoint[fe-oz919yuf-1-mj809yuf-bruz48-x21o4c5] sendTransaction [ur4-b6b39yuf-1-mj809yuf-bruz48-x21
> o4c5]
> javax.jms.IllegalStateException: Cannot find session with id ie-qz919yuf-1-mj809yuf-bruz48-x21o4c5
> 	at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.processTransaction(ServerConnectionEndpoi
> nt.java:835)
> 	at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.
> java:497)
> 	at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$Co
> nnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:101)
> 	at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.inv
> okeTarget(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
> I have attached a slightly doctors version of the EJB3 MDB example code,  it has been changed to introduce a sleep of 5 seconds in the MDB (to keep the transaction active longer) and also introduces a higher volume of messages to give you a chance to get to the JMX console and call stopDelivery.  If you don't get an exception on the first attempt it is worth trying again as the transaction must be in flight for the problem to occur.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 12:26:29 2009
From: jira-events at lists.jboss.org (Philip Dodds (JIRA))
Date: Mon, 20 Jul 2009 12:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1870) stopDelivery on
 active MDB results in exception (Session not found)
Message-ID: <830057413.1248107189559.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

stopDelivery on active MDB results in exception (Session not found)
-------------------------------------------------------------------

                 Key: EJBTHREE-1870
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1870
             Project: EJB 3.0
          Issue Type: Bug
          Components: ejb3
    Affects Versions: 1.1.3
         Environment: Mac OS/X Leopard, JDK 6, JBoss 5.1.0GA
            Reporter: Philip Dodds
         Attachments: stopdelivery-mdb.zip

If you start an MDB and introduce a messages to it then use the stopDelivery method of the MDB's MBean to stop it consuming messages you get an exception.  Note this problem only occurs if the MDB has a transaction in flight when the stopDelivery is called.

2009-05-20 12:30:52,499 ERROR [org.jboss.messaging.util.ExceptionUtil] (WorkManager(2)-44) Connectio
nEndpoint[fe-oz919yuf-1-mj809yuf-bruz48-x21o4c5] sendTransaction [ur4-b6b39yuf-1-mj809yuf-bruz48-x21
o4c5]
javax.jms.IllegalStateException: Cannot find session with id ie-qz919yuf-1-mj809yuf-bruz48-x21o4c5
	at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.processTransaction(ServerConnectionEndpoi
nt.java:835)
	at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.
java:497)
	at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$Co
nnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:101)
	at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.inv
okeTarget(ConnectionAdvised$sendTransaction_N3268650789275322226.java)

I have attached a slightly doctors version of the EJB3 MDB example code,  it has been changed to introduce a sleep of 5 seconds in the MDB (to keep the transaction active longer) and also introduces a higher volume of messages to give you a chance to get to the JMX console and call stopDelivery.  If you don't get an exception on the first attempt it is worth trying again as the transaction must be in flight for the problem to occur.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 18 10:18:42 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Sat, 18 Jul 2009 10:18:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <201682156.1247926722104.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476769#action_12476769 ] 

Richard Achmatowicz commented on JGRP-1011:
-------------------------------------------

Performed manual tests for udp and tcp with IPv4 addresses and the tests looked OK.

Started two instances of Draw with IPv6 addresses and did not see evidence of JGRP-984. There was extensive checking of this issue earlier in the week as well. So far, we have been unable to reproduce it.

Modified versions and tagged the release as JGroups_2_6_11_GA. Unfortunately forgot to check in the release notes into docs/ReleaseNotes-JGroups2.6.11.txt so committed them to Branch_2_6 subsequent to tagging.


 

> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>         Attachments: JGroups_2_6_11_GA_reports.zip
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 18 10:20:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Sat, 18 Jul 2009 10:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <588652331.1247926829319.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476771#action_12476771 ] 

Richard Achmatowicz commented on JGRP-1011:
-------------------------------------------

Checked out JGroups_2_6_11_GA. Built the distribution against JDK 1.5. 
Uploaded the jars to maven2 repository. 

> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>         Attachments: JGroups_2_6_11_GA_reports.zip
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 09:24:29 2009
From: jira-events at lists.jboss.org (Luke Dywicki (JIRA))
Date: Mon, 20 Jul 2009 09:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1690) Bridge does
 not use targetCffName property
Message-ID: <846953131.1248096269430.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Bridge does not use targetCffName property
------------------------------------------

                 Key: JBMESSAGING-1690
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1690
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.4.2.GA
         Environment: n/a
            Reporter: Luke Dywicki
            Assignee: Tim Fox


Bridge does not use targetCffName property. It always will be overriden by conditions inside setupJMSObjects method. There is no way to set this value over JMX.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 09:26:29 2009
From: jira-events at lists.jboss.org (Luke Dywicki (JIRA))
Date: Mon, 20 Jul 2009 09:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1690) Bridge does
 not use targetCffName property
In-Reply-To: <846953131.1248096269430.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <714660035.1248096389274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luke Dywicki updated JBMESSAGING-1690:
--------------------------------------

    Attachment: targetCFF.diff


Patch provided. 

> Bridge does not use targetCffName property
> ------------------------------------------
>
>                 Key: JBMESSAGING-1690
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1690
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.2.GA
>         Environment: n/a
>            Reporter: Luke Dywicki
>            Assignee: Tim Fox
>         Attachments: targetCFF.diff
>
>
> Bridge does not use targetCffName property. It always will be overriden by conditions inside setupJMSObjects method. There is no way to set this value over JMX.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 09:06:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 20 Jul 2009 09:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1728479848.1248095189240.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476852#action_12476852 ] 

Howard Gao commented on JBMESSAGING-1664:
-----------------------------------------

true. I'll think of some alternative. Maybe we can do the same job by a 'smart' sql statement, but I tried to create one but found I'm not smart enough to come up with one. :) So I'm thinking that such sql if exist must be a complex one and hard to maintain across different DB. So I gave up easily and turn to the programmatic way.

I'll think hard....


Howard


> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 09:15:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 20 Jul 2009 09:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <890403370.1248095729757.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476853#action_12476853 ] 

Tim Fox commented on JBMESSAGING-1664:
--------------------------------------

Isn't the problem here because it's reloading *non persistent* messages on startup.. if you only loaded the persistent messages would the problem go away?

> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 09:24:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 20 Jul 2009 09:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <727329041.1248096269256.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476854#action_12476854 ] 

Howard Gao commented on JBMESSAGING-1664:
-----------------------------------------

No. It all about persistent messages. The problem is that the 'paged' messages in downCache are not really paged onto DB, so those messages remain 'not paged' in DB records (i.e. the corresponding PAGE_ORD column are null). When some messages are delivered and the server is shut down, there are chances that when server start again some of the messages that originally in the down cache may be loaded in to in-memory queue. But the correct behavior is that they shouldn't be loaded, rather they should remain as paged messages.


> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 10:02:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jul 2009 10:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1013) STATE_TRANSFER /
 STREAMING_STATE_TRANSFER: close BARRIER before applying state response
In-Reply-To: <1427570229.1248080069185.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <224198724.1248098549279.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1013.
----------------------------

    Resolution: Done


Fixed according to suggested solution

> STATE_TRANSFER / STREAMING_STATE_TRANSFER: close BARRIER before applying state response
> ---------------------------------------------------------------------------------------
>
>                 Key: JGRP-1013
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1013
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.6.11, 2.8
>
>
> Current, both state transfer protocols close the barrier, process the state *request* and re-open it. However, this is NOT done for state *responses* !
> The following issue could happen:
> - D requests the state from A
> - B multicasts #11
> - D receives the digest A:5, B:10, C:44 and (in parallel) B:11
> Scenario #1:
> - [NAKACK] D applies the digest (is 10 for B)
> - [NAKACK] D receives B:11 (is 11 now for B)
> - D delivers B:11 to the app, changes state
> - D sets state, overwrites the change made by B:11
> --> B:11 will *not* get retransmitted as the digest in NAKACK already has it: the change made by B:11 is lost !
> Scenario #2:
> - [NAKACK] D receives B:11 (is 11 now for B)
> - [NAKACK] D applies the digest: resets the digest for B to #10
> - D sets state
> - D delivers B:11 to the app, changes state
> --> B:11 will get retransmitted as the digest in NAKACK doesn't contain it
> --> B:11 changes state *again*: B:11 is delivered *twice* !
> So scenario #1 loses B:11 while scenario #2 delivers B:11 twice, which has to be prevented.
> SOLUTION: 
> - Close BARRIER before state response is handled (similar to what we do with a state request)
> - This way, either B:11 is handled and changes the digest in NAKACK and the app state *before* we set the digest in NAKACK and the app state, OR the digest is set in NAKACK and the app state is set from the state response and THEN B:11 is handled

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 09:33:29 2009
From: jira-events at lists.jboss.org (Werner van Mook (JIRA))
Date: Mon, 20 Jul 2009 09:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-90) Using enum and
 switch with hybernate and jboss caching annotations gives an error while
 deploying in jboss AS5.1
Message-ID: <1228424485.1248096809669.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Using enum and switch with hybernate and jboss caching annotations gives an error while deploying in jboss AS5.1
----------------------------------------------------------------------------------------------------------------

                 Key: JASSIST-90
                 URL: https://jira.jboss.org/jira/browse/JASSIST-90
             Project: Javassist
          Issue Type: Bug
         Environment: JBoss 5.1.0.GA  (according to javassist manifest version 3.9.0.GA which is not in versions list) Sun JDK/JRE build 1.6.0_11-b03 Windows XP 5.1, x86
            Reporter: Werner van Mook
            Assignee: Shigeru Chiba


In an entity bean of type Request (See source) a method is defined with a switch statement. The switch statement is using enum values in the case. The Request class has annotations @Entity and @Replicable and for some object methods @Id and @GeneratedValue.

In a class called HelperClass (See source) an enum is defined. The HelperClass has annotation @Replicable.

After compile with ant script (See source) and starting JBoss with "-c all" an VerifyError occurs (See stackTrace)

Changing the switch statement into a nested if / else block makes it work.

<---------src---------->

Request.java:

package entity;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

import org.jboss.cache.pojo.annotation.Replicable;

@Entity
@Replicable
public class Request {
	
	private long id;
	private String filename;
	
	
	public Request(){
	}

	/**
	 * @return the id
	 */
	@Id
	@GeneratedValue
	public long getId() {
		return id;
	}

	/**
	 * @param id the id to set
	 */
	public void setId(long id) {
		this.id = id;
	}

	/**
	 * @return the filename
	 */
	public String getFilename() {
		return filename;
	}

	/**
	 * @param filename the filename to set
	 */
	public void setFilename(String filename) {
		this.filename = filename;
	}

	@Override
	public String toString() {
		return "id: " + id + " filename: " + filename;
	}
	
	public void inform() {
		HelperClass help = new HelperClass();
		informDeviceStateWhileHavingFullLock(help);
	}
	
	private void informDeviceStateWhileHavingFullLock(HelperClass osDeviceState) {
		switch (osDeviceState.getRuntimeStateRange()) {		
			case PROBLEM_CONNECTING: 
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case PROBLEM_SENDING:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case CONNECTED:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case INVALID:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case INTERRUPTED:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case STOPPED:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			default:
				System.out.println("Device state default is always ignored");			
				break;
		}
	}
}

HelperClass.java

package entity;

import org.jboss.cache.pojo.annotation.Replicable;
import org.jboss.cache.pojo.annotation.Transient;


@Replicable
public class HelperClass {

	private RuntimeStateRange runtimeState = RuntimeStateRange.RESTING;
	
	public static enum RuntimeStateRange {
		OFFLINE, 
		CONNECTED, 
		PROBLEM, 
		PROBLEM_CONNECTING,
		PROBLEM_SENDING,
		INTERRUPTED,
		STOPPED,
		INVALID,
		RESTING,
		BUSY,
		INITIALIZING }; 
		
	public HelperClass() {
		System.out.println("HelperClass created.");
	}

	public int EnumgetRuntimeState() {
		return runtimeState.ordinal();
	}
	
	public RuntimeStateRange getRuntimeStateRange(){
		return runtimeState;
	}
}


<--------------------------END src --------------->

<-------------------Stack trace ------------------>
15:09:15,730 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
15:09:15,730 INFO  [ServerImpl] Release ID: JBoss [The Oracle] 5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)
15:09:15,730 INFO  [ServerImpl] Bootstrap URL: null
15:09:15,730 INFO  [ServerImpl] Home Dir: C:\Java\jboss-5.1.0.GA
15:09:15,730 INFO  [ServerImpl] Home URL: file:/C:/Java/jboss-5.1.0.GA/
15:09:15,730 INFO  [ServerImpl] Library URL: file:/C:/Java/jboss-5.1.0.GA/lib/
15:09:15,730 INFO  [ServerImpl] Patch URL: null
15:09:15,730 INFO  [ServerImpl] Common Base URL: file:/C:/Java/jboss-5.1.0.GA/common/
15:09:15,746 INFO  [ServerImpl] Common Library URL: file:/C:/Java/jboss-5.1.0.GA/common/lib/
15:09:15,746 INFO  [ServerImpl] Server Name: all
15:09:15,746 INFO  [ServerImpl] Server Base Dir: C:\Java\jboss-5.1.0.GA\server
15:09:15,746 INFO  [ServerImpl] Server Base URL: file:/C:/Java/jboss-5.1.0.GA/server/
15:09:15,746 INFO  [ServerImpl] Server Config URL: file:/C:/Java/jboss-5.1.0.GA/server/all/conf/
15:09:15,746 INFO  [ServerImpl] Server Home Dir: C:\Java\jboss-5.1.0.GA\server\all
15:09:15,746 INFO  [ServerImpl] Server Home URL: file:/C:/Java/jboss-5.1.0.GA/server/all/
15:09:15,746 INFO  [ServerImpl] Server Data Dir: C:\Java\jboss-5.1.0.GA\server\all\data
15:09:15,746 INFO  [ServerImpl] Server Library URL: file:/C:/Java/jboss-5.1.0.GA/server/all/lib/
15:09:15,746 INFO  [ServerImpl] Server Log Dir: C:\Java\jboss-5.1.0.GA\server\all\log
15:09:15,746 INFO  [ServerImpl] Server Native Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp\native
15:09:15,746 INFO  [ServerImpl] Server Temp Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp
15:09:15,746 INFO  [ServerImpl] Server Temp Deploy Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp\deploy
15:09:16,355 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Java/jboss-5.1.0.GA/server/all/conf/bootstrap.xml
15:09:16,886 INFO  [VFSCacheFactory] Initializing VFSCache [org.jboss.virtual.plugins.cache.CombinedVFSCache]
15:09:16,886 INFO  [VFSCacheFactory] Using VFSCache [CombinedVFSCache[real-cache: null]]
15:09:17,152 INFO  [CopyMechanism] VFS temp dir: C:\Java\jboss-5.1.0.GA\server\all\tmp
15:09:17,152 INFO  [ZipEntryContext] VFS force nested jars copy-mode is enabled.
15:09:18,043 INFO  [ServerInfo] Java version: 1.6.0_11,Sun Microsystems Inc.
15:09:18,043 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
15:09:18,043 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 11.0-b16,Sun Microsystems Inc.
15:09:18,043 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
15:09:18,043 INFO  [ServerInfo] VM arguments: -Djboss.home=C:/Java/jboss-5.1.0.GA -Djava.library.path=C:/Program Files/Java/jdk1.6.0_11/bin -Djava.endorsed.dirs=C:/Java/jboss-5.1.0.GA/lib/endorsed -Xms256m -Xmx512m -XX:MaxPermSize=256m -Djboss.partition.name=Wernie -Dfile.encoding=Cp1252 
15:09:18,105 INFO  [JMXKernel] Legacy JMX core initialized
15:09:19,652 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 453dd5[domain=default, server=default, name=all]
15:09:21,246 INFO  [WebService] Using RMI server codebase: http://HHDEV06:8083/
15:09:26,089 INFO  [NativeServerConfig] JBoss Web Services - Stack Native Core
15:09:26,089 INFO  [NativeServerConfig] 3.1.2.GA
15:09:26,886 INFO  [AttributeCallbackItem] Owner callback not implemented.
15:09:28,495 INFO  [LogNotificationListener] Adding notification listener for logging mbean "jboss.system:service=Logging,type=Log4jService" to server org.jboss.mx.server.MBeanServerImpl at 23d278[ defaultDomain='jboss' ]
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,182 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 1507654{vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/test_clustered_slsb.jar/}
15:09:40,182 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 1507654{vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/test_clustered_slsb.jar/}
15:09:41,322 INFO  [CorbaNamingService] CORBA Naming Started
15:09:45,869 INFO  [JMXConnectorServerService] JMX Connector server: service:jmx:rmi://HHDEV06/jndi/rmi://HHDEV06:1090/jmxconnector
15:09:46,103 INFO  [MailService] Mail Service bound to java:/Mail
15:09:46,681 INFO  [SnmpAgentService] SNMP agent going active
15:09:49,166 INFO  [Wernie] Initializing partition Wernie
15:09:49,291 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2335 (cluster=Wernie)
---------------------------------------------------------
15:09:49,416 INFO  [PlatformMBeanServerRegistration] JBossCache MBeans were successfully registered to the platform mbean server.
15:09:49,447 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2335 (cluster=Wernie-HAPartitionCache)
---------------------------------------------------------
15:09:51,369 INFO  [Wernie] Number of cluster members: 1
15:09:51,384 INFO  [Wernie] Other members: 0
15:09:51,462 INFO  [RPCManagerImpl] Received new cluster view: [192.168.100.98:2335|0] [192.168.100.98:2335]
15:09:51,462 INFO  [RPCManagerImpl] Cache local address is 192.168.100.98:2335
15:09:51,462 INFO  [RPCManagerImpl] state was retrieved successfully (in 2,02 seconds)
15:09:51,478 INFO  [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA
15:09:51,478 INFO  [Wernie] Fetching serviceState (will wait for 30000 milliseconds):
15:09:51,478 INFO  [Wernie] State could not be retrieved (we are the first member in group)
15:09:51,556 INFO  [HANamingService] Started HAJNDI bootstrap; jnpPort=1100, backlog=50, bindAddress=/0.0.0.0
15:09:51,572 INFO  [DetachedHANamingService$AutomaticDiscovery] Listening on /0.0.0.0:1102, group=230.0.0.4, HA-JNDI address=192.168.100.98:1100
15:09:52,494 INFO  [UnifiedInvokerHA] Service name is jboss:service=invoker,type=unifiedha
15:09:53,040 WARN  [JBossASSecurityMetadataStore] WARNING! POTENTIAL SECURITY RISK. It has been detected that the MessageSucker component which sucks messages from one node to another has not had its password changed from the installation default. Please see the JBoss Messaging user guide for instructions on how to do this.
15:09:53,072 WARN  [AnnotationCreator] No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
15:09:53,212 WARN  [AnnotationCreator] No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
15:09:53,290 INFO  [TransactionManagerService] JBossTS Transaction Service (JTA version - tag:JBOSSTS_4_6_1_GA) - JBoss Inc.
15:09:53,290 INFO  [TransactionManagerService] Setting up property manager MBean and JMX layer
15:09:54,337 INFO  [TransactionManagerService] Initializing recovery manager
15:09:54,478 INFO  [TransactionManagerService] Recovery manager configured
15:09:54,478 INFO  [TransactionManagerService] Binding TransactionManager JNDI Reference
15:09:54,525 INFO  [TransactionManagerService] Starting transaction recovery manager
15:09:55,025 INFO  [AprLifecycleListener] The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:/Program Files/Java/jdk1.6.0_11/bin
15:09:55,087 INFO  [Http11Protocol] Initializing Coyote HTTP/1.1 on http-0.0.0.0-8080
15:09:55,087 INFO  [AjpProtocol] Initializing Coyote AJP/1.3 on ajp-0.0.0.0-8009
15:09:55,103 INFO  [StandardService] Starting service jboss.web
15:09:55,118 INFO  [StandardEngine] Starting Servlet Engine: JBoss Web/2.1.3.GA
15:09:55,181 INFO  [Catalina] Server startup in 91 ms
15:09:55,197 INFO  [TomcatDeployment] deploy, ctxPath=/juddi
15:09:55,743 INFO  [RegistryServlet] Loading jUDDI configuration.
15:09:55,743 INFO  [RegistryServlet] Resources loaded from: /WEB-INF/juddi.properties
15:09:55,743 INFO  [RegistryServlet] Initializing jUDDI components.
15:09:55,962 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
15:09:56,009 INFO  [TomcatDeployment] deploy, ctxPath=/web-console
15:09:57,462 INFO  [TomcatDeployment] deploy, ctxPath=/jbossws
15:09:57,618 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jboss-local-jdbc.rar/META-INF/ra.xml
15:09:57,634 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jboss-xa-jdbc.rar/META-INF/ra.xml
15:09:57,665 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jms-ra.rar/META-INF/ra.xml
15:09:57,696 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/mail-ra.rar/META-INF/ra.xml
15:09:57,712 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/quartz-ra.rar/META-INF/ra.xml
15:09:57,806 INFO  [SimpleThreadPool] Job execution threads will use class loader of thread: main
15:09:57,853 INFO  [QuartzScheduler] Quartz Scheduler v.1.5.2 created.
15:09:57,853 INFO  [RAMJobStore] RAMJobStore initialized.
15:09:57,853 INFO  [StdSchedulerFactory] Quartz scheduler 'DefaultQuartzScheduler' initialized from default resource file in Quartz package: 'quartz.properties'
15:09:57,853 INFO  [StdSchedulerFactory] Quartz scheduler version: 1.5.2
15:09:57,853 INFO  [QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
15:09:58,368 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
15:09:58,915 INFO  [ServerPeer] JBoss Messaging 1.4.3.GA server [0] started
15:09:59,134 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2335 (cluster=MessagingPostOffice-CTRL)
---------------------------------------------------------
15:10:01,149 INFO  [GroupMember] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 52bb2d got new view [192.168.100.98:2335|0] [192.168.100.98:2335], old view is null
15:10:01,149 INFO  [GroupMember] I am (192.168.100.98:2335)
15:10:01,149 INFO  [GroupMember] New Members : 1 ([192.168.100.98:2335])
15:10:01,149 INFO  [GroupMember] All Members : 1 ([192.168.100.98:2335])
15:10:01,181 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:7900 (cluster=MessagingPostOffice-DATA)
---------------------------------------------------------
15:10:07,227 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
15:10:07,227 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at bfd4f6 started
15:10:07,258 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
15:10:07,258 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at 1c977ef started
15:10:07,274 INFO  [QueueService] Queue[/queue/DLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:10:07,305 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
15:10:07,305 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at 14647e5 started
15:10:07,305 INFO  [QueueService] Queue[/queue/ExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:10:07,461 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'
15:10:07,883 INFO  [JBossASKernel] Created KernelDeployment for: profileservice-secured.jar
15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3
15:10:07,883 INFO  [JBossASKernel]   with dependencies:
15:10:07,883 INFO  [JBossASKernel]   and demands:
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView
15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:07,883 INFO  [JBossASKernel]   and supplies:
15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.profileservice.spi.ProfileService
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureProfileService/remote
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureProfileService/remote-org.jboss.profileservice.spi.ProfileService
15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3) to KernelDeployment of: profileservice-secured.jar
15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3
15:10:07,883 INFO  [JBossASKernel]   with dependencies:
15:10:07,883 INFO  [JBossASKernel]   and demands:
15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:07,883 INFO  [JBossASKernel]   and supplies:
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureDeploymentManager/remote-org.jboss.deployers.spi.management.deploy.DeploymentManager
15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.deployers.spi.management.deploy.DeploymentManager
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureDeploymentManager/remote
15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3) to KernelDeployment of: profileservice-secured.jar
15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3
15:10:07,883 INFO  [JBossASKernel]   with dependencies:
15:10:07,883 INFO  [JBossASKernel]   and demands:
15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:07,883 INFO  [JBossASKernel]   and supplies:
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView
15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.deployers.spi.management.ManagementView
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote
15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3) to KernelDeployment of: profileservice-secured.jar
15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at f5f77{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 1bd9f3d{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 98fc6a{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:08,024 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3
15:10:08,039 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureDeploymentManager ejbName: SecureDeploymentManager
15:10:08,102 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	SecureDeploymentManager/remote - EJB3.x Default Remote Business Interface
	SecureDeploymentManager/remote-org.jboss.deployers.spi.management.deploy.DeploymentManager - EJB3.x Remote Business Interface

15:10:08,196 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3
15:10:08,196 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureManagementView ejbName: SecureManagementView
15:10:08,211 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	SecureManagementView/remote - EJB3.x Default Remote Business Interface
	SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView - EJB3.x Remote Business Interface

15:10:08,274 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3
15:10:08,274 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureProfileServiceBean ejbName: SecureProfileService
15:10:08,305 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	SecureProfileService/remote - EJB3.x Default Remote Business Interface
	SecureProfileService/remote-org.jboss.profileservice.spi.ProfileService - EJB3.x Remote Business Interface

15:10:08,414 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3
15:10:08,414 INFO  [JBossASKernel]   with dependencies:
15:10:08,414 INFO  [JBossASKernel]   and demands:
15:10:08,414 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:08,414 INFO  [JBossASKernel]   and supplies:
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local
15:10:08,414 INFO  [JBossASKernel] 	Class:service.ITestServiceBeanManagement
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/remote
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
15:10:08,414 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3) to KernelDeployment of: test_clustered_slsb.jar
15:10:08,414 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3
15:10:08,414 INFO  [JBossASKernel]   with dependencies:
15:10:08,414 INFO  [JBossASKernel]   and demands:
15:10:08,414 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
15:10:08,414 INFO  [JBossASKernel]   and supplies:
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestClusteredBean/remote
15:10:08,414 INFO  [JBossASKernel] 	Class:session.ITestClusteredBean
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestClusteredBean/remote-session.ITestClusteredBean
15:10:08,414 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3) to KernelDeployment of: test_clustered_slsb.jar
15:10:08,414 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at ad588a{name=jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:08,602 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:08,618 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:08,649 INFO  [PlatformMBeanServerRegistration] JBossCache MBeans were successfully registered to the platform mbean server.
15:10:08,711 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2353 (cluster=Wernie-UnistreamPojoCache)
---------------------------------------------------------
15:10:10,774 INFO  [RPCManagerImpl] Received new cluster view: [192.168.100.98:2353|0] [192.168.100.98:2353]
15:10:10,774 INFO  [RPCManagerImpl] Cache local address is 192.168.100.98:2353
15:10:10,774 INFO  [RPCManagerImpl] state was retrieved successfully (in 2,11 seconds)
15:10:10,774 INFO  [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:10,930 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3,type=ManagementInterface
15:10:10,930 INFO  [JBossASKernel]   with dependencies:
15:10:10,930 INFO  [JBossASKernel]   and demands:
15:10:10,930 INFO  [JBossASKernel] 	jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3
15:10:10,930 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:10,930 INFO  [JBossASKernel]   and supplies:
15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/local
15:10:10,930 INFO  [JBossASKernel] 	Class:service.ITestServiceBeanManagement
15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/remote
15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
15:10:10,930 INFO  [JBossASKernel] Installing bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3,type=ManagementInterface) into kernel
15:10:10,961 WARN  [UniStreamCacheListener] ::::  UniStreamCacheListener created  ::::
15:10:10,961 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:10,961 INFO  [STDOUT] Create of TestServiceBean
15:10:10,961 INFO  [EJBContainer] STARTED EJB: service.TestServiceBean ejbName: TestServiceBean
15:10:10,977 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	TestServiceBean/local - EJB3.x Default Local Business Interface
	TestServiceBean/local-service.ITestServiceBeanLocal - EJB3.x Local Business Interface

15:10:11,024 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3
15:10:11,024 INFO  [EJBContainer] STARTED EJB: session.TestClusteredBean ejbName: TestClusteredBean
15:10:11,071 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	TestClusteredBean/remote - EJB3.x Default Remote Business Interface
	TestClusteredBean/remote-session.ITestClusteredBean - EJB3.x Remote Business Interface

15:10:11,102 INFO  [PersistenceUnitDeployment] Starting persistence unit persistence.unit:unitName=#unistream
15:10:11,196 INFO  [Version] Hibernate Annotations 3.4.0.GA
15:10:11,227 INFO  [Environment] Hibernate 3.3.1.GA
15:10:11,242 INFO  [Environment] hibernate.properties not found
15:10:11,242 INFO  [Environment] Bytecode provider name : javassist
15:10:11,242 INFO  [Environment] using JDK 1.4 java.sql.Timestamp handling
15:10:11,383 INFO  [Version] Hibernate Commons Annotations 3.1.0.GA
15:10:11,383 INFO  [Version] Hibernate EntityManager 3.4.0.GA
15:10:11,430 INFO  [Ejb3Configuration] Processing PersistenceUnitInfo [
	name: unistream
	...]
15:10:11,461 WARN  [Ejb3Configuration] Persistence provider caller does not implement the EJB3 spec correctly. PersistenceUnitInfo.getNewTempClassLoader() is null.
15:10:11,570 INFO  [AnnotationBinder] Binding entity from annotated class: entity.Request
15:10:11,664 INFO  [EntityBinder] Bind entity entity.Request on table Request
15:10:11,680 ERROR [AbstractKernelController] Error installing to Start: name=persistence.unit:unitName=#unistream state=Create
java.lang.VerifyError: (class: entity/Request, method: informDeviceStateWhileHavingFullLock signature: (Lentity/HelperClass;)V) Unable to pop operand off an empty stack
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
	at java.lang.Class.getDeclaredMethods(Class.java:1791)
	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredMethodProperties(JavaXClass.java:89)
	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredProperties(JavaXClass.java:106)
	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredProperties(JavaXClass.java:98)
	at org.hibernate.cfg.AnnotationBinder.addElementsOfAClass(AnnotationBinder.java:1023)
	at org.hibernate.cfg.AnnotationBinder.getElementsToProcess(AnnotationBinder.java:859)
	at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:667)
	at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:546)
	at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:291)
	at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1148)
	at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1226)
	at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:173)
	at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:854)
	at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:425)
	at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:131)
	at org.jboss.jpa.deployment.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:301)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	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.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
	at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
	at org.jboss.Main.boot(Main.java:221)
	at org.jboss.Main$1.run(Main.java:556)
	at java.lang.Thread.run(Thread.java:619)
15:10:11,774 INFO  [TomcatDeployment] deploy, ctxPath=/admin-console
15:10:11,852 INFO  [config] Initializing Mojarra (1.2_12-b01-FCS) for context '/admin-console'
15:10:15,680 INFO  [TomcatDeployment] deploy, ctxPath=/
15:10:15,726 INFO  [TomcatDeployment] deploy, ctxPath=/jmx-console
15:10:15,883 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

DEPLOYMENTS IN ERROR:
  Deployment "persistence.unit:unitName=#unistream" is in error due to the following reason(s): java.lang.VerifyError: (class: entity/Request, method: informDeviceStateWhileHavingFullLock signature: (Lentity/HelperClass;)V) Unable to pop operand off an empty stack

15:10:15,883 INFO  [Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8080
15:10:15,914 INFO  [AjpProtocol] Starting Coyote AJP/1.3 on ajp-0.0.0.0-8009
15:10:15,930 INFO  [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 1m:184ms


<----------------------END Stack trace ----------------------->



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 08:59:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 20 Jul 2009 08:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1659) Create source
	distribution
In-Reply-To: <1154159.1245315667976.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <669924223.1248094769338.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1659.
------------------------------------

    Resolution: Done


added source-distro target to the trunk

> Create source distribution
> --------------------------
>
>                 Key: JBMESSAGING-1659
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1659
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Build System
>    Affects Versions: 2.0.0.beta2
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> JBoss Messaging build systems creates only binary distributions.
> We must also create source distributions which contains the source.
> An alternative is to always include the source in the distributions (the src dir is 4,4M and 1M when zipped)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 08:59:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 20 Jul 2009 08:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1063889122.1248094769227.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476850#action_12476850 ] 

Tim Fox commented on JBMESSAGING-1664:
--------------------------------------

That may be true for some databases but we can't assume they all support database cursors

> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 08:57:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 20 Jul 2009 08:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <853455039.1248094649446.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476849#action_12476849 ] 

Howard Gao commented on JBMESSAGING-1664:
-----------------------------------------

Yes, I'm thinking about it. The changes makes the ResultSet become large, but not in the JBM server, rather in the DB server.
We just iterate through the result set and only store the needed records. So it shouldn't be a memory burden for JBM server.



> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 09:52:30 2009
From: jira-events at lists.jboss.org (Werner van Mook (JIRA))
Date: Mon, 20 Jul 2009 09:52:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JASSIST-90) Using enum and
 switch with hybernate and jboss caching annotations gives an error while
 deploying in jboss AS5.1
In-Reply-To: <1228424485.1248096809669.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <874135220.1248097950639.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Werner van Mook updated JASSIST-90:
-----------------------------------

    Description: 
In an entity bean of type Request (See source) a method is defined with a switch statement. The switch statement is using enum values in the case. The Request class has annotations @Entity and @Replicable and for some object methods @Id and @GeneratedValue.

In a class called HelperClass (See source) an enum is defined. The HelperClass has annotation @Replicable.

After compile with ant script (See source) and starting JBoss with "-c all" an VerifyError occurs (See stackTrace)

Changing the switch statement into a nested if / else block makes it work.

<---------src---------->

Request.java:

package entity;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

import org.jboss.cache.pojo.annotation.Replicable;

@Entity
@Replicable
public class Request {
	
	private long id;
	private String filename;
	
	
	public Request(){
	}

	/**
	 * @return the id
	 */
	@Id
	@GeneratedValue
	public long getId() {
		return id;
	}

	/**
	 * @param id the id to set
	 */
	public void setId(long id) {
		this.id = id;
	}

	/**
	 * @return the filename
	 */
	public String getFilename() {
		return filename;
	}

	/**
	 * @param filename the filename to set
	 */
	public void setFilename(String filename) {
		this.filename = filename;
	}

	@Override
	public String toString() {
		return "id: " + id + " filename: " + filename;
	}
	
	public void inform() {
		HelperClass help = new HelperClass();
		informDeviceStateWhileHavingFullLock(help);
	}
	
	private void informDeviceStateWhileHavingFullLock(HelperClass osDeviceState) {
		switch (osDeviceState.getRuntimeStateRange()) {		
			case PROBLEM_CONNECTING: 
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case PROBLEM_SENDING:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case CONNECTED:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case INVALID:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case INTERRUPTED:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case STOPPED:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			default:
				System.out.println("Device state default is always ignored");			
				break;
		}
	}
}

HelperClass.java

package entity;

import org.jboss.cache.pojo.annotation.Replicable;
import org.jboss.cache.pojo.annotation.Transient;


@Replicable
public class HelperClass {

	private RuntimeStateRange runtimeState = RuntimeStateRange.RESTING;
	
	public static enum RuntimeStateRange {
		OFFLINE, 
		CONNECTED, 
		PROBLEM, 
		PROBLEM_CONNECTING,
		PROBLEM_SENDING,
		INTERRUPTED,
		STOPPED,
		INVALID,
		RESTING,
		BUSY,
		INITIALIZING }; 
		
	public HelperClass() {
		System.out.println("HelperClass created.");
	}

	public int EnumgetRuntimeState() {
		return runtimeState.ordinal();
	}
	
	public RuntimeStateRange getRuntimeStateRange(){
		return runtimeState;
	}
}


<--------------------------END src --------------->

<-------------------Stack trace ------------------>
15:09:15,730 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
15:09:15,730 INFO  [ServerImpl] Release ID: JBoss [The Oracle] 5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)
15:09:15,730 INFO  [ServerImpl] Bootstrap URL: null
15:09:15,730 INFO  [ServerImpl] Home Dir: C:\Java\jboss-5.1.0.GA
15:09:15,730 INFO  [ServerImpl] Home URL: file:/C:/Java/jboss-5.1.0.GA/
15:09:15,730 INFO  [ServerImpl] Library URL: file:/C:/Java/jboss-5.1.0.GA/lib/
15:09:15,730 INFO  [ServerImpl] Patch URL: null
15:09:15,730 INFO  [ServerImpl] Common Base URL: file:/C:/Java/jboss-5.1.0.GA/common/
15:09:15,746 INFO  [ServerImpl] Common Library URL: file:/C:/Java/jboss-5.1.0.GA/common/lib/
15:09:15,746 INFO  [ServerImpl] Server Name: all
15:09:15,746 INFO  [ServerImpl] Server Base Dir: C:\Java\jboss-5.1.0.GA\server
15:09:15,746 INFO  [ServerImpl] Server Base URL: file:/C:/Java/jboss-5.1.0.GA/server/
15:09:15,746 INFO  [ServerImpl] Server Config URL: file:/C:/Java/jboss-5.1.0.GA/server/all/conf/
15:09:15,746 INFO  [ServerImpl] Server Home Dir: C:\Java\jboss-5.1.0.GA\server\all
15:09:15,746 INFO  [ServerImpl] Server Home URL: file:/C:/Java/jboss-5.1.0.GA/server/all/
15:09:15,746 INFO  [ServerImpl] Server Data Dir: C:\Java\jboss-5.1.0.GA\server\all\data
15:09:15,746 INFO  [ServerImpl] Server Library URL: file:/C:/Java/jboss-5.1.0.GA/server/all/lib/
15:09:15,746 INFO  [ServerImpl] Server Log Dir: C:\Java\jboss-5.1.0.GA\server\all\log
15:09:15,746 INFO  [ServerImpl] Server Native Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp\native
15:09:15,746 INFO  [ServerImpl] Server Temp Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp
15:09:15,746 INFO  [ServerImpl] Server Temp Deploy Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp\deploy
15:09:16,355 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Java/jboss-5.1.0.GA/server/all/conf/bootstrap.xml
15:09:16,886 INFO  [VFSCacheFactory] Initializing VFSCache [org.jboss.virtual.plugins.cache.CombinedVFSCache]
15:09:16,886 INFO  [VFSCacheFactory] Using VFSCache [CombinedVFSCache[real-cache: null]]
15:09:17,152 INFO  [CopyMechanism] VFS temp dir: C:\Java\jboss-5.1.0.GA\server\all\tmp
15:09:17,152 INFO  [ZipEntryContext] VFS force nested jars copy-mode is enabled.
15:09:18,043 INFO  [ServerInfo] Java version: 1.6.0_11,Sun Microsystems Inc.
15:09:18,043 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
15:09:18,043 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 11.0-b16,Sun Microsystems Inc.
15:09:18,043 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
15:09:18,043 INFO  [ServerInfo] VM arguments: -Djboss.home=C:/Java/jboss-5.1.0.GA -Djava.library.path=C:/Program Files/Java/jdk1.6.0_11/bin -Djava.endorsed.dirs=C:/Java/jboss-5.1.0.GA/lib/endorsed -Xms256m -Xmx512m -XX:MaxPermSize=256m -Djboss.partition.name=Wernie -Dfile.encoding=Cp1252 
15:09:18,105 INFO  [JMXKernel] Legacy JMX core initialized
15:09:19,652 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 453dd5[domain=default, server=default, name=all]
15:09:21,246 INFO  [WebService] Using RMI server codebase: http://HHDEV06:8083/
15:09:26,089 INFO  [NativeServerConfig] JBoss Web Services - Stack Native Core
15:09:26,089 INFO  [NativeServerConfig] 3.1.2.GA
15:09:26,886 INFO  [AttributeCallbackItem] Owner callback not implemented.
15:09:28,495 INFO  [LogNotificationListener] Adding notification listener for logging mbean "jboss.system:service=Logging,type=Log4jService" to server org.jboss.mx.server.MBeanServerImpl at 23d278[ defaultDomain='jboss' ]
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,182 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 1507654{vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/test_clustered_slsb.jar/}
15:09:40,182 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 1507654{vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/test_clustered_slsb.jar/}
15:09:41,322 INFO  [CorbaNamingService] CORBA Naming Started
15:09:45,869 INFO  [JMXConnectorServerService] JMX Connector server: service:jmx:rmi://HHDEV06/jndi/rmi://HHDEV06:1090/jmxconnector
15:09:46,103 INFO  [MailService] Mail Service bound to java:/Mail
15:09:46,681 INFO  [SnmpAgentService] SNMP agent going active
15:09:49,166 INFO  [Wernie] Initializing partition Wernie
15:09:49,291 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2335 (cluster=Wernie)
---------------------------------------------------------
15:09:49,416 INFO  [PlatformMBeanServerRegistration] JBossCache MBeans were successfully registered to the platform mbean server.
15:09:49,447 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2335 (cluster=Wernie-HAPartitionCache)
---------------------------------------------------------
15:09:51,369 INFO  [Wernie] Number of cluster members: 1
15:09:51,384 INFO  [Wernie] Other members: 0
15:09:51,462 INFO  [RPCManagerImpl] Received new cluster view: [192.168.100.98:2335|0] [192.168.100.98:2335]
15:09:51,462 INFO  [RPCManagerImpl] Cache local address is 192.168.100.98:2335
15:09:51,462 INFO  [RPCManagerImpl] state was retrieved successfully (in 2,02 seconds)
15:09:51,478 INFO  [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA
15:09:51,478 INFO  [Wernie] Fetching serviceState (will wait for 30000 milliseconds):
15:09:51,478 INFO  [Wernie] State could not be retrieved (we are the first member in group)
15:09:51,556 INFO  [HANamingService] Started HAJNDI bootstrap; jnpPort=1100, backlog=50, bindAddress=/0.0.0.0
15:09:51,572 INFO  [DetachedHANamingService$AutomaticDiscovery] Listening on /0.0.0.0:1102, group=230.0.0.4, HA-JNDI address=192.168.100.98:1100
15:09:52,494 INFO  [UnifiedInvokerHA] Service name is jboss:service=invoker,type=unifiedha
15:09:53,040 WARN  [JBossASSecurityMetadataStore] WARNING! POTENTIAL SECURITY RISK. It has been detected that the MessageSucker component which sucks messages from one node to another has not had its password changed from the installation default. Please see the JBoss Messaging user guide for instructions on how to do this.
15:09:53,072 WARN  [AnnotationCreator] No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
15:09:53,212 WARN  [AnnotationCreator] No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
15:09:53,290 INFO  [TransactionManagerService] JBossTS Transaction Service (JTA version - tag:JBOSSTS_4_6_1_GA) - JBoss Inc.
15:09:53,290 INFO  [TransactionManagerService] Setting up property manager MBean and JMX layer
15:09:54,337 INFO  [TransactionManagerService] Initializing recovery manager
15:09:54,478 INFO  [TransactionManagerService] Recovery manager configured
15:09:54,478 INFO  [TransactionManagerService] Binding TransactionManager JNDI Reference
15:09:54,525 INFO  [TransactionManagerService] Starting transaction recovery manager
15:09:55,025 INFO  [AprLifecycleListener] The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:/Program Files/Java/jdk1.6.0_11/bin
15:09:55,087 INFO  [Http11Protocol] Initializing Coyote HTTP/1.1 on http-0.0.0.0-8080
15:09:55,087 INFO  [AjpProtocol] Initializing Coyote AJP/1.3 on ajp-0.0.0.0-8009
15:09:55,103 INFO  [StandardService] Starting service jboss.web
15:09:55,118 INFO  [StandardEngine] Starting Servlet Engine: JBoss Web/2.1.3.GA
15:09:55,181 INFO  [Catalina] Server startup in 91 ms
15:09:55,197 INFO  [TomcatDeployment] deploy, ctxPath=/juddi
15:09:55,743 INFO  [RegistryServlet] Loading jUDDI configuration.
15:09:55,743 INFO  [RegistryServlet] Resources loaded from: /WEB-INF/juddi.properties
15:09:55,743 INFO  [RegistryServlet] Initializing jUDDI components.
15:09:55,962 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
15:09:56,009 INFO  [TomcatDeployment] deploy, ctxPath=/web-console
15:09:57,462 INFO  [TomcatDeployment] deploy, ctxPath=/jbossws
15:09:57,618 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jboss-local-jdbc.rar/META-INF/ra.xml
15:09:57,634 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jboss-xa-jdbc.rar/META-INF/ra.xml
15:09:57,665 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jms-ra.rar/META-INF/ra.xml
15:09:57,696 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/mail-ra.rar/META-INF/ra.xml
15:09:57,712 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/quartz-ra.rar/META-INF/ra.xml
15:09:57,806 INFO  [SimpleThreadPool] Job execution threads will use class loader of thread: main
15:09:57,853 INFO  [QuartzScheduler] Quartz Scheduler v.1.5.2 created.
15:09:57,853 INFO  [RAMJobStore] RAMJobStore initialized.
15:09:57,853 INFO  [StdSchedulerFactory] Quartz scheduler 'DefaultQuartzScheduler' initialized from default resource file in Quartz package: 'quartz.properties'
15:09:57,853 INFO  [StdSchedulerFactory] Quartz scheduler version: 1.5.2
15:09:57,853 INFO  [QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
15:09:58,368 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
15:09:58,915 INFO  [ServerPeer] JBoss Messaging 1.4.3.GA server [0] started
15:09:59,134 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2335 (cluster=MessagingPostOffice-CTRL)
---------------------------------------------------------
15:10:01,149 INFO  [GroupMember] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 52bb2d got new view [192.168.100.98:2335|0] [192.168.100.98:2335], old view is null
15:10:01,149 INFO  [GroupMember] I am (192.168.100.98:2335)
15:10:01,149 INFO  [GroupMember] New Members : 1 ([192.168.100.98:2335])
15:10:01,149 INFO  [GroupMember] All Members : 1 ([192.168.100.98:2335])
15:10:01,181 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:7900 (cluster=MessagingPostOffice-DATA)
---------------------------------------------------------
15:10:07,227 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
15:10:07,227 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at bfd4f6 started
15:10:07,258 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
15:10:07,258 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at 1c977ef started
15:10:07,274 INFO  [QueueService] Queue[/queue/DLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:10:07,305 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
15:10:07,305 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at 14647e5 started
15:10:07,305 INFO  [QueueService] Queue[/queue/ExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:10:07,461 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'
15:10:07,883 INFO  [JBossASKernel] Created KernelDeployment for: profileservice-secured.jar
15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3
15:10:07,883 INFO  [JBossASKernel]   with dependencies:
15:10:07,883 INFO  [JBossASKernel]   and demands:
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView
15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:07,883 INFO  [JBossASKernel]   and supplies:
15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.profileservice.spi.ProfileService
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureProfileService/remote
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureProfileService/remote-org.jboss.profileservice.spi.ProfileService
15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3) to KernelDeployment of: profileservice-secured.jar
15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3
15:10:07,883 INFO  [JBossASKernel]   with dependencies:
15:10:07,883 INFO  [JBossASKernel]   and demands:
15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:07,883 INFO  [JBossASKernel]   and supplies:
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureDeploymentManager/remote-org.jboss.deployers.spi.management.deploy.DeploymentManager
15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.deployers.spi.management.deploy.DeploymentManager
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureDeploymentManager/remote
15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3) to KernelDeployment of: profileservice-secured.jar
15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3
15:10:07,883 INFO  [JBossASKernel]   with dependencies:
15:10:07,883 INFO  [JBossASKernel]   and demands:
15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:07,883 INFO  [JBossASKernel]   and supplies:
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView
15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.deployers.spi.management.ManagementView
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote
15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3) to KernelDeployment of: profileservice-secured.jar
15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at f5f77{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 1bd9f3d{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 98fc6a{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:08,024 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3
15:10:08,039 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureDeploymentManager ejbName: SecureDeploymentManager
15:10:08,102 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	SecureDeploymentManager/remote - EJB3.x Default Remote Business Interface
	SecureDeploymentManager/remote-org.jboss.deployers.spi.management.deploy.DeploymentManager - EJB3.x Remote Business Interface

15:10:08,196 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3
15:10:08,196 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureManagementView ejbName: SecureManagementView
15:10:08,211 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	SecureManagementView/remote - EJB3.x Default Remote Business Interface
	SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView - EJB3.x Remote Business Interface

15:10:08,274 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3
15:10:08,274 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureProfileServiceBean ejbName: SecureProfileService
15:10:08,305 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	SecureProfileService/remote - EJB3.x Default Remote Business Interface
	SecureProfileService/remote-org.jboss.profileservice.spi.ProfileService - EJB3.x Remote Business Interface

15:10:08,414 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3
15:10:08,414 INFO  [JBossASKernel]   with dependencies:
15:10:08,414 INFO  [JBossASKernel]   and demands:
15:10:08,414 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:08,414 INFO  [JBossASKernel]   and supplies:
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local
15:10:08,414 INFO  [JBossASKernel] 	Class:service.ITestServiceBeanManagement
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/remote
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
15:10:08,414 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3) to KernelDeployment of: test_clustered_slsb.jar
15:10:08,414 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3
15:10:08,414 INFO  [JBossASKernel]   with dependencies:
15:10:08,414 INFO  [JBossASKernel]   and demands:
15:10:08,414 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
15:10:08,414 INFO  [JBossASKernel]   and supplies:
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestClusteredBean/remote
15:10:08,414 INFO  [JBossASKernel] 	Class:session.ITestClusteredBean
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestClusteredBean/remote-session.ITestClusteredBean
15:10:08,414 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3) to KernelDeployment of: test_clustered_slsb.jar
15:10:08,414 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at ad588a{name=jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:08,602 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:08,618 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:08,649 INFO  [PlatformMBeanServerRegistration] JBossCache MBeans were successfully registered to the platform mbean server.
15:10:08,711 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2353 (cluster=Wernie-UnistreamPojoCache)
---------------------------------------------------------
15:10:10,774 INFO  [RPCManagerImpl] Received new cluster view: [192.168.100.98:2353|0] [192.168.100.98:2353]
15:10:10,774 INFO  [RPCManagerImpl] Cache local address is 192.168.100.98:2353
15:10:10,774 INFO  [RPCManagerImpl] state was retrieved successfully (in 2,11 seconds)
15:10:10,774 INFO  [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:10,930 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3,type=ManagementInterface
15:10:10,930 INFO  [JBossASKernel]   with dependencies:
15:10:10,930 INFO  [JBossASKernel]   and demands:
15:10:10,930 INFO  [JBossASKernel] 	jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3
15:10:10,930 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:10,930 INFO  [JBossASKernel]   and supplies:
15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/local
15:10:10,930 INFO  [JBossASKernel] 	Class:service.ITestServiceBeanManagement
15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/remote
15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
15:10:10,930 INFO  [JBossASKernel] Installing bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3,type=ManagementInterface) into kernel
15:10:10,961 WARN  [UniStreamCacheListener] ::::  UniStreamCacheListener created  ::::
15:10:10,961 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:10,961 INFO  [STDOUT] Create of TestServiceBean
15:10:10,961 INFO  [EJBContainer] STARTED EJB: service.TestServiceBean ejbName: TestServiceBean
15:10:10,977 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	TestServiceBean/local - EJB3.x Default Local Business Interface
	TestServiceBean/local-service.ITestServiceBeanLocal - EJB3.x Local Business Interface

15:10:11,024 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3
15:10:11,024 INFO  [EJBContainer] STARTED EJB: session.TestClusteredBean ejbName: TestClusteredBean
15:10:11,071 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	TestClusteredBean/remote - EJB3.x Default Remote Business Interface
	TestClusteredBean/remote-session.ITestClusteredBean - EJB3.x Remote Business Interface

15:10:11,102 INFO  [PersistenceUnitDeployment] Starting persistence unit persistence.unit:unitName=#unistream
15:10:11,196 INFO  [Version] Hibernate Annotations 3.4.0.GA
15:10:11,227 INFO  [Environment] Hibernate 3.3.1.GA
15:10:11,242 INFO  [Environment] hibernate.properties not found
15:10:11,242 INFO  [Environment] Bytecode provider name : javassist
15:10:11,242 INFO  [Environment] using JDK 1.4 java.sql.Timestamp handling
15:10:11,383 INFO  [Version] Hibernate Commons Annotations 3.1.0.GA
15:10:11,383 INFO  [Version] Hibernate EntityManager 3.4.0.GA
15:10:11,430 INFO  [Ejb3Configuration] Processing PersistenceUnitInfo [
	name: unistream
	...]
15:10:11,461 WARN  [Ejb3Configuration] Persistence provider caller does not implement the EJB3 spec correctly. PersistenceUnitInfo.getNewTempClassLoader() is null.
15:10:11,570 INFO  [AnnotationBinder] Binding entity from annotated class: entity.Request
15:10:11,664 INFO  [EntityBinder] Bind entity entity.Request on table Request
15:10:11,680 ERROR [AbstractKernelController] Error installing to Start: name=persistence.unit:unitName=#unistream state=Create
java.lang.VerifyError: (class: entity/Request, method: informDeviceStateWhileHavingFullLock signature: (Lentity/HelperClass;)V) Unable to pop operand off an empty stack
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
	at java.lang.Class.getDeclaredMethods(Class.java:1791)
	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredMethodProperties(JavaXClass.java:89)
	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredProperties(JavaXClass.java:106)
	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredProperties(JavaXClass.java:98)
	at org.hibernate.cfg.AnnotationBinder.addElementsOfAClass(AnnotationBinder.java:1023)
	at org.hibernate.cfg.AnnotationBinder.getElementsToProcess(AnnotationBinder.java:859)
	at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:667)
	at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:546)
	at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:291)
	at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1148)
	at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1226)
	at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:173)
	at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:854)
	at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:425)
	at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:131)
	at org.jboss.jpa.deployment.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:301)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	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.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
	at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
	at org.jboss.Main.boot(Main.java:221)
	at org.jboss.Main$1.run(Main.java:556)
	at java.lang.Thread.run(Thread.java:619)
15:10:11,774 INFO  [TomcatDeployment] deploy, ctxPath=/admin-console
15:10:11,852 INFO  [config] Initializing Mojarra (1.2_12-b01-FCS) for context '/admin-console'
15:10:15,680 INFO  [TomcatDeployment] deploy, ctxPath=/
15:10:15,726 INFO  [TomcatDeployment] deploy, ctxPath=/jmx-console
15:10:15,883 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

DEPLOYMENTS IN ERROR:
  Deployment "persistence.unit:unitName=#unistream" is in error due to the following reason(s): java.lang.VerifyError: (class: entity/Request, method: informDeviceStateWhileHavingFullLock signature: (Lentity/HelperClass;)V) Unable to pop operand off an empty stack

15:10:15,883 INFO  [Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8080
15:10:15,914 INFO  [AjpProtocol] Starting Coyote AJP/1.3 on ajp-0.0.0.0-8009
15:10:15,930 INFO  [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 1m:184ms


<----------------------END Stack trace ----------------------->



<----------------------- Ant file ------------------------->
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE project [
	<!ENTITY properties SYSTEM "../../../unispool7/config/buildfiles/properties.xml">
]>
<project default="deploy2Jboss" name="TestClusteredSessionBean" basedir="../..">

	<!-- read the properties from file -->
	&properties;

	<target name="prepare">
		<path id="classpath">
			<path refid="jboss.aop.classpath"/>
			<path refid="jboss.class.path"/>
			<pathelement path="bin"/>
		</path>
	</target>

	<target name="compile" depends="prepare">
		<delete dir="bin"/>
		<mkdir dir="bin"/>
		<javac srcdir="src" destdir="bin" deprecation="on" optimize="off" includes="**">
			<classpath refid="classpath"/>
		</javac>

		<copy todir="bin" filtering="no">
			<fileset dir="config/properties">
				<include name="**/*.properties"/>
			</fileset>
			<fileset dir="config">
				<include name="**/persistence.xml"/>
				<include name="**/unistream-pojo-cache-jboss-beans.xml"/>
			</fileset>
		</copy>
	</target>

	<target name="aopc" depends="compile">
		<unjar src="${jbossServerLib}/jbosscache-pojo.jar" dest="bin">
			<mapper type="flatten"/>
			<patternset>
        		<include name="**/pojocache-aop.xml"/>
    		</patternset>
		</unjar>
		<aopc compilerclasspathref="classpath" classpathref="classpath" verbose="true">
			<classpath path="bin"/>
			<src path="bin"/>
			<aoppath path="bin/pojocache-aop.xml"/>
			<aopclasspath path="bin"/>
		</aopc>
	</target>

	<target name="package-server-jar" depends="aopc" description="Create JAR File">
		<jar destfile="build/test_clustered_slsb.jar">
			<fileset dir="bin">
                <include name="**/*.*"/>
                <exclude name="**/Main.*"/>
                <exclude name="**/jndi.properties"/>
                <exclude name="**/pojocache-aop.xml"/>
			</fileset>
		</jar>
	</target>

	<target name="run-compile-time" depends="aopc">
		<java fork="yes" failOnError="true" className="Main">
			<sysproperty key="jboss.aop.path" value="bin/pojocache-aop.xml"/>
			<sysproperty key="jboss.aop.class.path" value="bin"/>
			<classpath refid="classpath"/>
		</java>
	</target>
	
	<target name="deploy2Jboss" depends="package-server-jar" description="Deploy the JAR File to JBoss">
		<copy file="build/test_clustered_slsb.jar" tofile="C:\Java\jboss-5.1.0.GA\server\all\deploy\test_clustered_slsb.jar"/>
	</target>

</project>






The properties file used by ant:





<!-- Read in the environment variables -->
<property environment="env"/>

<!-- Inits the properties -->
<tstamp/>

<!-- needed for if, switch tasks -->
<taskdef resource="net/sf/antcontrib/antcontrib.properties"/>
<taskdef resource="net/sf/antcontrib/antlib.xml"/>

<!-- base directories -->
<property name="src" location="${basedir}/src"/>
<property name="conf" location="${basedir}/config"/>
<property name="build" location="${basedir}/build"/>
<property name="dist" location="${basedir}/dist"/>
<property name="dist-obfuscated" location="${basedir}/dist-obfuscated"/>
<property name="ext" location="${basedir}/ext"/>
<property name="app" value="com/hollandhouse/unistream"/>

<!-- src directories -->
<property name="src" location="${src}"/>
<property name="HhLog4j" location="${src}/com/hollandhouse/unistream/framework/log/log4j/"/>

<!-- conf directories -->
<property name="conf-xml" location="${conf}/XML"/>
<property name="conf-jboss" location="${conf}/JBoss"/>
<property name="conf-properties" location="${conf}/properties"/>
<property name="conf-properties-server" location="${conf-properties}/server"/>
<property name="conf-properties-agent" location="${conf-properties}/agent"/>
<property name="conf-mergefiles" location="${conf}/mergefiles"/>
<property name="conf-buildfiles" location="${conf}/buildfiles"/>
<property name="conf-cache" location="${conf}/cache"/>

<!-- build directories -->
<property name="build-generated" location="${build}/generated"/>
<property name="generated.java.dir" value="${build-generated}"/>
<property name="build-classes" location="${build}/classes"/>
<property name="build-resources" location="${build}/resources"/>
<property name="build-doc" location="${build}/doc"/>
<property name="build-web" location="${build}/web"/>

<!-- file names -->
<property name="ejb-file" value="unistream-ejb3.jar"/>
<property name="ejb-agent-file" value="unistream-agent.jar"/>
<property name="sar-file" value="unistream.sar"/>
<property name="sar-agent-file" value="unistream-agent.sar"/>
<property name="entities-jar-file" value="entities.jar"/>
<property name="jar-entities-agent-file" value="entities-agent.jar"/>
<property name="war-file" value="unistream.war"/>
<property name="jar-hhlog4j-file" value="hhlog4j.jar"/>
<property name="xml-hhlog4j-file" value="log4j_unistream.xml"/>
<property name="common-file" value="unistream-framework.jar"/>
<property name="cli-file" value="unistream-cli.jar"/>
<property name="ear-file" value="unistream.ear"/>
<property name="ear-agent-file" value="unistream-agent.ear"/>
<property name="swing-gui-file" value="unistream-swing-gui.jar"/>
<property name="swing-gui-doc-file" value="unistream-swing-gui-doc.zip"/>
<property name="testpage-file" value="UNISTREAM-TESTFILE"/>
<property name="usPojoCache-file" value="unistream-pojo-cache-jboss-beans.xml"/>

<!-- build test directories -->
<property name="build-tests" location="${build}/tests"/>
<property name="build-reports" location="${build}/reports"/>

<!-- jboss settings main -->
<property name="jbossServerProfile" value="unistream_main"/>

<property name="jbossServer" location="${env.JBOSS_HOME}/server/${jbossServerProfile}"/>
<property name="jbossDeploy" location="${jbossServer}/deploy"/>
<property name="jbossServerLib" location="${jbossServer}/lib"/>
<property name="jbossConfig" location="${jbossServer}/conf"/>

<!-- jboss settings agent -->
<property name="jbossAgentProfile" value="unistream_agent"/>

<property name="jbossAgent" location="${env.JBOSS_HOME}/server/${jbossAgentProfile}"/>
<property name="jbossAgentDeploy" location="${jbossAgent}/deploy"/>
<property name="jbossAgentLib" location="${jbossAgent}/lib"/>
<property name="jbossAgentConfig" location="${jbossAgent}/conf"/>

<!-- jboss settings common -->
<property name="jbossLib" location="${env.JBOSS_HOME}/lib"/>
<property name="jbossClientLib" value="${env.JBOSS_HOME}/client"/>
<property name="jbossCommonLib" location="${env.JBOSS_HOME}/common/lib"/>

<!--        <property name="jbossDataSource" value="java:/mysqlDS"/>
<property name="jbossDataSourceMapping" value="mySQL"/> -->
<property name="jbossDataSource" value="java:/DefaultDS"/>
<property name="jbossDataSourceMapping" value="Hypersonic SQL"/>

<!-- Temp General manifest file -->
<property name="manifest-general" location="${build}/manifest_gen.txt"/>
<!-- Temp ClassPath manifest file -->
<property name="manifest-classpath" location="${build}/manifest_cp.txt"/>

<property name="version-file" value="unistream-version"/>

<!--  jboss properties files -->
<property name="xml-hhlog4j-path" location="${conf-properties-server}/${xml-hhlog4j-file}"/>
<property name="xml-hhlog4j-agent-path" location="${conf-properties-agent}/${xml-hhlog4j-file}"/>

<!-- setup the project class paths -->

<path id="jboss.class.path">
	<fileset dir="${jbossLib}">
		<include name="*.jar"/>
	</fileset>
	<fileset dir="${env.JBOSS_HOME}/client">
		<include name="*.jar"/>
	</fileset>
	<fileset dir="${jbossCommonLib}">
		<include name="*.jar"/>
	</fileset>
	<fileset dir="${jbossServerLib}">
		<include name="*.jar"/>
	</fileset>
</path>

<path id="ext.class.path">
	<path refid="jboss.class.path"/>
	<fileset dir="${ext}">
		<include name="**/*.jar"/>
	</fileset>
</path>

<path id="jboss.aop.classpath">
	<fileset dir="${jbossLib}">
		<include name="jboss-aop.jar"/>
	</fileset>
</path>

<!-- setup the project class paths -->
<path id="project.class.path">
	<path refid="ext.class.path"/>
	<path refid="jboss.aop.classpath"/>
</path>

<!-- Define the JBoss AOP compiler Ant task -->
<taskdef name="aopc" classname="org.jboss.aop.ant.AopC" classpathref="jboss.aop.classpath"/>

<path id="junit.test.class.path">
	<path refid="ext.class.path"/>
	<fileset dir="${dist}">
		<include name="*.jar"/>
		<include name="*.sar"/>
		<exclude name="*-agent.*"/>
	</fileset>
	<pathelement location="${conf-properties}"/>
	<pathelement location="${build-classes}"/>
</path>

<!-- Project Libraries -->

<property name="gui-jar-path" value="${basedir}/unistreamgui.jar"/>

<path id="library.gui_jars.classpath">
	<pathelement location="${jbossClientLib}/commons-logging.jar"/>
	<pathelement location="${jbossClientLib}/concurrent.jar"/>
	<pathelement location="${jbossClientLib}/ejb3-persistence.jar"/>
	<pathelement location="${jbossClientLib}/hibernate-annotations.jar"/>
	<pathelement location="${jbossClientLib}/javassist.jar"/>
	<pathelement location="${jbossClientLib}/jbossall-client.jar"/>
	<pathelement location="${jbossClientLib}/jboss-aop-client.jar"/>
	<pathelement location="${jbossClientLib}/jboss-aspect-jdk50-client.jar"/>
	<pathelement location="${jbossClientLib}/jboss-common-core.jar"/>
	<pathelement location="${jbossClientLib}/jboss-ejb3-common-client.jar"/>
	<pathelement location="${jbossClientLib}/jboss-ejb3-core-client.jar"/>
	<pathelement location="${jbossClientLib}/jboss-ejb3-ext-api.jar"/>
	<pathelement location="${jbossClientLib}/jboss-ejb3-ext-api-impl.jar"/>
	<pathelement location="${jbossClientLib}/jboss-ejb3-proxy-impl-client.jar"/>
	<pathelement location="${jbossClientLib}/jboss-ejb3-proxy-spi-client.jar"/>
	<pathelement location="${jbossClientLib}/jboss-ejb3-security-client.jar"/>
	<pathelement location="${jbossClientLib}/jboss-integration.jar"/>
	<pathelement location="${jbossClientLib}/jboss-javaee.jar"/>
	<pathelement location="${jbossClientLib}/jboss-logging-log4j.jar"/>
	<pathelement location="${jbossClientLib}/jboss-logging-spi.jar"/>
	<pathelement location="${jbossClientLib}/jboss-mdr.jar"/>
	<pathelement location="${jbossClientLib}/jboss-messaging-client.jar"/>
	<pathelement location="${jbossClientLib}/jboss-remoting.jar"/>
	<pathelement location="${jbossClientLib}/jboss-security-spi.jar"/>
	<pathelement location="${jbossClientLib}/jboss-serialization.jar"/>
	<pathelement location="${jbossClientLib}/jbosssx-client.jar"/>
	<pathelement location="${jbossClientLib}/jnp-client.jar"/>
	<pathelement location="${jbossClientLib}/log4j.jar"/>
	<pathelement location="${jbossClientLib}/trove.jar"/>
	<pathelement location="${jbossCommonLib}/hibernate-core.jar"/>
</path>

<path id="library.javahelp.classpath">
	<pathelement location="${basedir}/jars/java help/jh2.0/javahelp/lib/jh.jar"/>
</path>

<!-- Global Libraries -->

<path id="library.junit.classpath">
	<pathelement location="${basedir}/jars/junit-4.0/junit-4.0.jar"/>
</path>






<----------------------END Ant file -------------->


  was:
In an entity bean of type Request (See source) a method is defined with a switch statement. The switch statement is using enum values in the case. The Request class has annotations @Entity and @Replicable and for some object methods @Id and @GeneratedValue.

In a class called HelperClass (See source) an enum is defined. The HelperClass has annotation @Replicable.

After compile with ant script (See source) and starting JBoss with "-c all" an VerifyError occurs (See stackTrace)

Changing the switch statement into a nested if / else block makes it work.

<---------src---------->

Request.java:

package entity;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

import org.jboss.cache.pojo.annotation.Replicable;

@Entity
@Replicable
public class Request {
	
	private long id;
	private String filename;
	
	
	public Request(){
	}

	/**
	 * @return the id
	 */
	@Id
	@GeneratedValue
	public long getId() {
		return id;
	}

	/**
	 * @param id the id to set
	 */
	public void setId(long id) {
		this.id = id;
	}

	/**
	 * @return the filename
	 */
	public String getFilename() {
		return filename;
	}

	/**
	 * @param filename the filename to set
	 */
	public void setFilename(String filename) {
		this.filename = filename;
	}

	@Override
	public String toString() {
		return "id: " + id + " filename: " + filename;
	}
	
	public void inform() {
		HelperClass help = new HelperClass();
		informDeviceStateWhileHavingFullLock(help);
	}
	
	private void informDeviceStateWhileHavingFullLock(HelperClass osDeviceState) {
		switch (osDeviceState.getRuntimeStateRange()) {		
			case PROBLEM_CONNECTING: 
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case PROBLEM_SENDING:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case CONNECTED:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case INVALID:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case INTERRUPTED:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			case STOPPED:
				System.out.println(osDeviceState.EnumgetRuntimeState());
				break; 
			default:
				System.out.println("Device state default is always ignored");			
				break;
		}
	}
}

HelperClass.java

package entity;

import org.jboss.cache.pojo.annotation.Replicable;
import org.jboss.cache.pojo.annotation.Transient;


@Replicable
public class HelperClass {

	private RuntimeStateRange runtimeState = RuntimeStateRange.RESTING;
	
	public static enum RuntimeStateRange {
		OFFLINE, 
		CONNECTED, 
		PROBLEM, 
		PROBLEM_CONNECTING,
		PROBLEM_SENDING,
		INTERRUPTED,
		STOPPED,
		INVALID,
		RESTING,
		BUSY,
		INITIALIZING }; 
		
	public HelperClass() {
		System.out.println("HelperClass created.");
	}

	public int EnumgetRuntimeState() {
		return runtimeState.ordinal();
	}
	
	public RuntimeStateRange getRuntimeStateRange(){
		return runtimeState;
	}
}


<--------------------------END src --------------->

<-------------------Stack trace ------------------>
15:09:15,730 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
15:09:15,730 INFO  [ServerImpl] Release ID: JBoss [The Oracle] 5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)
15:09:15,730 INFO  [ServerImpl] Bootstrap URL: null
15:09:15,730 INFO  [ServerImpl] Home Dir: C:\Java\jboss-5.1.0.GA
15:09:15,730 INFO  [ServerImpl] Home URL: file:/C:/Java/jboss-5.1.0.GA/
15:09:15,730 INFO  [ServerImpl] Library URL: file:/C:/Java/jboss-5.1.0.GA/lib/
15:09:15,730 INFO  [ServerImpl] Patch URL: null
15:09:15,730 INFO  [ServerImpl] Common Base URL: file:/C:/Java/jboss-5.1.0.GA/common/
15:09:15,746 INFO  [ServerImpl] Common Library URL: file:/C:/Java/jboss-5.1.0.GA/common/lib/
15:09:15,746 INFO  [ServerImpl] Server Name: all
15:09:15,746 INFO  [ServerImpl] Server Base Dir: C:\Java\jboss-5.1.0.GA\server
15:09:15,746 INFO  [ServerImpl] Server Base URL: file:/C:/Java/jboss-5.1.0.GA/server/
15:09:15,746 INFO  [ServerImpl] Server Config URL: file:/C:/Java/jboss-5.1.0.GA/server/all/conf/
15:09:15,746 INFO  [ServerImpl] Server Home Dir: C:\Java\jboss-5.1.0.GA\server\all
15:09:15,746 INFO  [ServerImpl] Server Home URL: file:/C:/Java/jboss-5.1.0.GA/server/all/
15:09:15,746 INFO  [ServerImpl] Server Data Dir: C:\Java\jboss-5.1.0.GA\server\all\data
15:09:15,746 INFO  [ServerImpl] Server Library URL: file:/C:/Java/jboss-5.1.0.GA/server/all/lib/
15:09:15,746 INFO  [ServerImpl] Server Log Dir: C:\Java\jboss-5.1.0.GA\server\all\log
15:09:15,746 INFO  [ServerImpl] Server Native Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp\native
15:09:15,746 INFO  [ServerImpl] Server Temp Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp
15:09:15,746 INFO  [ServerImpl] Server Temp Deploy Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp\deploy
15:09:16,355 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Java/jboss-5.1.0.GA/server/all/conf/bootstrap.xml
15:09:16,886 INFO  [VFSCacheFactory] Initializing VFSCache [org.jboss.virtual.plugins.cache.CombinedVFSCache]
15:09:16,886 INFO  [VFSCacheFactory] Using VFSCache [CombinedVFSCache[real-cache: null]]
15:09:17,152 INFO  [CopyMechanism] VFS temp dir: C:\Java\jboss-5.1.0.GA\server\all\tmp
15:09:17,152 INFO  [ZipEntryContext] VFS force nested jars copy-mode is enabled.
15:09:18,043 INFO  [ServerInfo] Java version: 1.6.0_11,Sun Microsystems Inc.
15:09:18,043 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
15:09:18,043 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 11.0-b16,Sun Microsystems Inc.
15:09:18,043 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
15:09:18,043 INFO  [ServerInfo] VM arguments: -Djboss.home=C:/Java/jboss-5.1.0.GA -Djava.library.path=C:/Program Files/Java/jdk1.6.0_11/bin -Djava.endorsed.dirs=C:/Java/jboss-5.1.0.GA/lib/endorsed -Xms256m -Xmx512m -XX:MaxPermSize=256m -Djboss.partition.name=Wernie -Dfile.encoding=Cp1252 
15:09:18,105 INFO  [JMXKernel] Legacy JMX core initialized
15:09:19,652 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 453dd5[domain=default, server=default, name=all]
15:09:21,246 INFO  [WebService] Using RMI server codebase: http://HHDEV06:8083/
15:09:26,089 INFO  [NativeServerConfig] JBoss Web Services - Stack Native Core
15:09:26,089 INFO  [NativeServerConfig] 3.1.2.GA
15:09:26,886 INFO  [AttributeCallbackItem] Owner callback not implemented.
15:09:28,495 INFO  [LogNotificationListener] Adding notification listener for logging mbean "jboss.system:service=Logging,type=Log4jService" to server org.jboss.mx.server.MBeanServerImpl at 23d278[ defaultDomain='jboss' ]
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
15:09:40,182 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 1507654{vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/test_clustered_slsb.jar/}
15:09:40,182 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 1507654{vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/test_clustered_slsb.jar/}
15:09:41,322 INFO  [CorbaNamingService] CORBA Naming Started
15:09:45,869 INFO  [JMXConnectorServerService] JMX Connector server: service:jmx:rmi://HHDEV06/jndi/rmi://HHDEV06:1090/jmxconnector
15:09:46,103 INFO  [MailService] Mail Service bound to java:/Mail
15:09:46,681 INFO  [SnmpAgentService] SNMP agent going active
15:09:49,166 INFO  [Wernie] Initializing partition Wernie
15:09:49,291 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2335 (cluster=Wernie)
---------------------------------------------------------
15:09:49,416 INFO  [PlatformMBeanServerRegistration] JBossCache MBeans were successfully registered to the platform mbean server.
15:09:49,447 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2335 (cluster=Wernie-HAPartitionCache)
---------------------------------------------------------
15:09:51,369 INFO  [Wernie] Number of cluster members: 1
15:09:51,384 INFO  [Wernie] Other members: 0
15:09:51,462 INFO  [RPCManagerImpl] Received new cluster view: [192.168.100.98:2335|0] [192.168.100.98:2335]
15:09:51,462 INFO  [RPCManagerImpl] Cache local address is 192.168.100.98:2335
15:09:51,462 INFO  [RPCManagerImpl] state was retrieved successfully (in 2,02 seconds)
15:09:51,478 INFO  [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA
15:09:51,478 INFO  [Wernie] Fetching serviceState (will wait for 30000 milliseconds):
15:09:51,478 INFO  [Wernie] State could not be retrieved (we are the first member in group)
15:09:51,556 INFO  [HANamingService] Started HAJNDI bootstrap; jnpPort=1100, backlog=50, bindAddress=/0.0.0.0
15:09:51,572 INFO  [DetachedHANamingService$AutomaticDiscovery] Listening on /0.0.0.0:1102, group=230.0.0.4, HA-JNDI address=192.168.100.98:1100
15:09:52,494 INFO  [UnifiedInvokerHA] Service name is jboss:service=invoker,type=unifiedha
15:09:53,040 WARN  [JBossASSecurityMetadataStore] WARNING! POTENTIAL SECURITY RISK. It has been detected that the MessageSucker component which sucks messages from one node to another has not had its password changed from the installation default. Please see the JBoss Messaging user guide for instructions on how to do this.
15:09:53,072 WARN  [AnnotationCreator] No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
15:09:53,212 WARN  [AnnotationCreator] No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
15:09:53,290 INFO  [TransactionManagerService] JBossTS Transaction Service (JTA version - tag:JBOSSTS_4_6_1_GA) - JBoss Inc.
15:09:53,290 INFO  [TransactionManagerService] Setting up property manager MBean and JMX layer
15:09:54,337 INFO  [TransactionManagerService] Initializing recovery manager
15:09:54,478 INFO  [TransactionManagerService] Recovery manager configured
15:09:54,478 INFO  [TransactionManagerService] Binding TransactionManager JNDI Reference
15:09:54,525 INFO  [TransactionManagerService] Starting transaction recovery manager
15:09:55,025 INFO  [AprLifecycleListener] The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:/Program Files/Java/jdk1.6.0_11/bin
15:09:55,087 INFO  [Http11Protocol] Initializing Coyote HTTP/1.1 on http-0.0.0.0-8080
15:09:55,087 INFO  [AjpProtocol] Initializing Coyote AJP/1.3 on ajp-0.0.0.0-8009
15:09:55,103 INFO  [StandardService] Starting service jboss.web
15:09:55,118 INFO  [StandardEngine] Starting Servlet Engine: JBoss Web/2.1.3.GA
15:09:55,181 INFO  [Catalina] Server startup in 91 ms
15:09:55,197 INFO  [TomcatDeployment] deploy, ctxPath=/juddi
15:09:55,743 INFO  [RegistryServlet] Loading jUDDI configuration.
15:09:55,743 INFO  [RegistryServlet] Resources loaded from: /WEB-INF/juddi.properties
15:09:55,743 INFO  [RegistryServlet] Initializing jUDDI components.
15:09:55,962 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
15:09:56,009 INFO  [TomcatDeployment] deploy, ctxPath=/web-console
15:09:57,462 INFO  [TomcatDeployment] deploy, ctxPath=/jbossws
15:09:57,618 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jboss-local-jdbc.rar/META-INF/ra.xml
15:09:57,634 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jboss-xa-jdbc.rar/META-INF/ra.xml
15:09:57,665 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jms-ra.rar/META-INF/ra.xml
15:09:57,696 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/mail-ra.rar/META-INF/ra.xml
15:09:57,712 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/quartz-ra.rar/META-INF/ra.xml
15:09:57,806 INFO  [SimpleThreadPool] Job execution threads will use class loader of thread: main
15:09:57,853 INFO  [QuartzScheduler] Quartz Scheduler v.1.5.2 created.
15:09:57,853 INFO  [RAMJobStore] RAMJobStore initialized.
15:09:57,853 INFO  [StdSchedulerFactory] Quartz scheduler 'DefaultQuartzScheduler' initialized from default resource file in Quartz package: 'quartz.properties'
15:09:57,853 INFO  [StdSchedulerFactory] Quartz scheduler version: 1.5.2
15:09:57,853 INFO  [QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
15:09:58,368 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
15:09:58,915 INFO  [ServerPeer] JBoss Messaging 1.4.3.GA server [0] started
15:09:59,134 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2335 (cluster=MessagingPostOffice-CTRL)
---------------------------------------------------------
15:10:01,149 INFO  [GroupMember] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 52bb2d got new view [192.168.100.98:2335|0] [192.168.100.98:2335], old view is null
15:10:01,149 INFO  [GroupMember] I am (192.168.100.98:2335)
15:10:01,149 INFO  [GroupMember] New Members : 1 ([192.168.100.98:2335])
15:10:01,149 INFO  [GroupMember] All Members : 1 ([192.168.100.98:2335])
15:10:01,181 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:7900 (cluster=MessagingPostOffice-DATA)
---------------------------------------------------------
15:10:07,227 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
15:10:07,227 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at bfd4f6 started
15:10:07,258 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
15:10:07,258 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at 1c977ef started
15:10:07,274 INFO  [QueueService] Queue[/queue/DLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:10:07,305 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
15:10:07,305 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at 14647e5 started
15:10:07,305 INFO  [QueueService] Queue[/queue/ExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
15:10:07,461 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'
15:10:07,883 INFO  [JBossASKernel] Created KernelDeployment for: profileservice-secured.jar
15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3
15:10:07,883 INFO  [JBossASKernel]   with dependencies:
15:10:07,883 INFO  [JBossASKernel]   and demands:
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView
15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:07,883 INFO  [JBossASKernel]   and supplies:
15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.profileservice.spi.ProfileService
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureProfileService/remote
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureProfileService/remote-org.jboss.profileservice.spi.ProfileService
15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3) to KernelDeployment of: profileservice-secured.jar
15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3
15:10:07,883 INFO  [JBossASKernel]   with dependencies:
15:10:07,883 INFO  [JBossASKernel]   and demands:
15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:07,883 INFO  [JBossASKernel]   and supplies:
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureDeploymentManager/remote-org.jboss.deployers.spi.management.deploy.DeploymentManager
15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.deployers.spi.management.deploy.DeploymentManager
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureDeploymentManager/remote
15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3) to KernelDeployment of: profileservice-secured.jar
15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3
15:10:07,883 INFO  [JBossASKernel]   with dependencies:
15:10:07,883 INFO  [JBossASKernel]   and demands:
15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:07,883 INFO  [JBossASKernel]   and supplies:
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView
15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.deployers.spi.management.ManagementView
15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote
15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3) to KernelDeployment of: profileservice-secured.jar
15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at f5f77{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 1bd9f3d{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 98fc6a{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:08,024 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3
15:10:08,039 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureDeploymentManager ejbName: SecureDeploymentManager
15:10:08,102 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	SecureDeploymentManager/remote - EJB3.x Default Remote Business Interface
	SecureDeploymentManager/remote-org.jboss.deployers.spi.management.deploy.DeploymentManager - EJB3.x Remote Business Interface

15:10:08,196 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3
15:10:08,196 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureManagementView ejbName: SecureManagementView
15:10:08,211 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	SecureManagementView/remote - EJB3.x Default Remote Business Interface
	SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView - EJB3.x Remote Business Interface

15:10:08,274 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3
15:10:08,274 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureProfileServiceBean ejbName: SecureProfileService
15:10:08,305 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	SecureProfileService/remote - EJB3.x Default Remote Business Interface
	SecureProfileService/remote-org.jboss.profileservice.spi.ProfileService - EJB3.x Remote Business Interface

15:10:08,414 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3
15:10:08,414 INFO  [JBossASKernel]   with dependencies:
15:10:08,414 INFO  [JBossASKernel]   and demands:
15:10:08,414 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:08,414 INFO  [JBossASKernel]   and supplies:
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local
15:10:08,414 INFO  [JBossASKernel] 	Class:service.ITestServiceBeanManagement
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/remote
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
15:10:08,414 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3) to KernelDeployment of: test_clustered_slsb.jar
15:10:08,414 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3
15:10:08,414 INFO  [JBossASKernel]   with dependencies:
15:10:08,414 INFO  [JBossASKernel]   and demands:
15:10:08,414 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
15:10:08,414 INFO  [JBossASKernel]   and supplies:
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestClusteredBean/remote
15:10:08,414 INFO  [JBossASKernel] 	Class:session.ITestClusteredBean
15:10:08,414 INFO  [JBossASKernel] 	jndi:TestClusteredBean/remote-session.ITestClusteredBean
15:10:08,414 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3) to KernelDeployment of: test_clustered_slsb.jar
15:10:08,414 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at ad588a{name=jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
15:10:08,602 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:08,618 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:08,649 INFO  [PlatformMBeanServerRegistration] JBossCache MBeans were successfully registered to the platform mbean server.
15:10:08,711 INFO  [STDOUT] 
---------------------------------------------------------
GMS: address is 192.168.100.98:2353 (cluster=Wernie-UnistreamPojoCache)
---------------------------------------------------------
15:10:10,774 INFO  [RPCManagerImpl] Received new cluster view: [192.168.100.98:2353|0] [192.168.100.98:2353]
15:10:10,774 INFO  [RPCManagerImpl] Cache local address is 192.168.100.98:2353
15:10:10,774 INFO  [RPCManagerImpl] state was retrieved successfully (in 2,11 seconds)
15:10:10,774 INFO  [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:10,930 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3,type=ManagementInterface
15:10:10,930 INFO  [JBossASKernel]   with dependencies:
15:10:10,930 INFO  [JBossASKernel]   and demands:
15:10:10,930 INFO  [JBossASKernel] 	jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3
15:10:10,930 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
15:10:10,930 INFO  [JBossASKernel]   and supplies:
15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/local
15:10:10,930 INFO  [JBossASKernel] 	Class:service.ITestServiceBeanManagement
15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/remote
15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
15:10:10,930 INFO  [JBossASKernel] Installing bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3,type=ManagementInterface) into kernel
15:10:10,961 WARN  [UniStreamCacheListener] ::::  UniStreamCacheListener created  ::::
15:10:10,961 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
15:10:10,961 INFO  [STDOUT] Create of TestServiceBean
15:10:10,961 INFO  [EJBContainer] STARTED EJB: service.TestServiceBean ejbName: TestServiceBean
15:10:10,977 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	TestServiceBean/local - EJB3.x Default Local Business Interface
	TestServiceBean/local-service.ITestServiceBeanLocal - EJB3.x Local Business Interface

15:10:11,024 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3
15:10:11,024 INFO  [EJBContainer] STARTED EJB: session.TestClusteredBean ejbName: TestClusteredBean
15:10:11,071 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

	TestClusteredBean/remote - EJB3.x Default Remote Business Interface
	TestClusteredBean/remote-session.ITestClusteredBean - EJB3.x Remote Business Interface

15:10:11,102 INFO  [PersistenceUnitDeployment] Starting persistence unit persistence.unit:unitName=#unistream
15:10:11,196 INFO  [Version] Hibernate Annotations 3.4.0.GA
15:10:11,227 INFO  [Environment] Hibernate 3.3.1.GA
15:10:11,242 INFO  [Environment] hibernate.properties not found
15:10:11,242 INFO  [Environment] Bytecode provider name : javassist
15:10:11,242 INFO  [Environment] using JDK 1.4 java.sql.Timestamp handling
15:10:11,383 INFO  [Version] Hibernate Commons Annotations 3.1.0.GA
15:10:11,383 INFO  [Version] Hibernate EntityManager 3.4.0.GA
15:10:11,430 INFO  [Ejb3Configuration] Processing PersistenceUnitInfo [
	name: unistream
	...]
15:10:11,461 WARN  [Ejb3Configuration] Persistence provider caller does not implement the EJB3 spec correctly. PersistenceUnitInfo.getNewTempClassLoader() is null.
15:10:11,570 INFO  [AnnotationBinder] Binding entity from annotated class: entity.Request
15:10:11,664 INFO  [EntityBinder] Bind entity entity.Request on table Request
15:10:11,680 ERROR [AbstractKernelController] Error installing to Start: name=persistence.unit:unitName=#unistream state=Create
java.lang.VerifyError: (class: entity/Request, method: informDeviceStateWhileHavingFullLock signature: (Lentity/HelperClass;)V) Unable to pop operand off an empty stack
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
	at java.lang.Class.getDeclaredMethods(Class.java:1791)
	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredMethodProperties(JavaXClass.java:89)
	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredProperties(JavaXClass.java:106)
	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredProperties(JavaXClass.java:98)
	at org.hibernate.cfg.AnnotationBinder.addElementsOfAClass(AnnotationBinder.java:1023)
	at org.hibernate.cfg.AnnotationBinder.getElementsToProcess(AnnotationBinder.java:859)
	at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:667)
	at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:546)
	at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:291)
	at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1148)
	at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1226)
	at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:173)
	at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:854)
	at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:425)
	at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:131)
	at org.jboss.jpa.deployment.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:301)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	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.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
	at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
	at org.jboss.Main.boot(Main.java:221)
	at org.jboss.Main$1.run(Main.java:556)
	at java.lang.Thread.run(Thread.java:619)
15:10:11,774 INFO  [TomcatDeployment] deploy, ctxPath=/admin-console
15:10:11,852 INFO  [config] Initializing Mojarra (1.2_12-b01-FCS) for context '/admin-console'
15:10:15,680 INFO  [TomcatDeployment] deploy, ctxPath=/
15:10:15,726 INFO  [TomcatDeployment] deploy, ctxPath=/jmx-console
15:10:15,883 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

DEPLOYMENTS IN ERROR:
  Deployment "persistence.unit:unitName=#unistream" is in error due to the following reason(s): java.lang.VerifyError: (class: entity/Request, method: informDeviceStateWhileHavingFullLock signature: (Lentity/HelperClass;)V) Unable to pop operand off an empty stack

15:10:15,883 INFO  [Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8080
15:10:15,914 INFO  [AjpProtocol] Starting Coyote AJP/1.3 on ajp-0.0.0.0-8009
15:10:15,930 INFO  [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 1m:184ms


<----------------------END Stack trace ----------------------->





I forgot the ant file the first time. So now included the ant file and the properties file used by the build file.

> Using enum and switch with hybernate and jboss caching annotations gives an error while deploying in jboss AS5.1
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-90
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-90
>             Project: Javassist
>          Issue Type: Bug
>         Environment: JBoss 5.1.0.GA  (according to javassist manifest version 3.9.0.GA which is not in versions list) Sun JDK/JRE build 1.6.0_11-b03 Windows XP 5.1, x86
>            Reporter: Werner van Mook
>            Assignee: Shigeru Chiba
>
> In an entity bean of type Request (See source) a method is defined with a switch statement. The switch statement is using enum values in the case. The Request class has annotations @Entity and @Replicable and for some object methods @Id and @GeneratedValue.
> In a class called HelperClass (See source) an enum is defined. The HelperClass has annotation @Replicable.
> After compile with ant script (See source) and starting JBoss with "-c all" an VerifyError occurs (See stackTrace)
> Changing the switch statement into a nested if / else block makes it work.
> <---------src---------->
> Request.java:
> package entity;
> import javax.persistence.Entity;
> import javax.persistence.GeneratedValue;
> import javax.persistence.Id;
> import org.jboss.cache.pojo.annotation.Replicable;
> @Entity
> @Replicable
> public class Request {
> 	
> 	private long id;
> 	private String filename;
> 	
> 	
> 	public Request(){
> 	}
> 	/**
> 	 * @return the id
> 	 */
> 	@Id
> 	@GeneratedValue
> 	public long getId() {
> 		return id;
> 	}
> 	/**
> 	 * @param id the id to set
> 	 */
> 	public void setId(long id) {
> 		this.id = id;
> 	}
> 	/**
> 	 * @return the filename
> 	 */
> 	public String getFilename() {
> 		return filename;
> 	}
> 	/**
> 	 * @param filename the filename to set
> 	 */
> 	public void setFilename(String filename) {
> 		this.filename = filename;
> 	}
> 	@Override
> 	public String toString() {
> 		return "id: " + id + " filename: " + filename;
> 	}
> 	
> 	public void inform() {
> 		HelperClass help = new HelperClass();
> 		informDeviceStateWhileHavingFullLock(help);
> 	}
> 	
> 	private void informDeviceStateWhileHavingFullLock(HelperClass osDeviceState) {
> 		switch (osDeviceState.getRuntimeStateRange()) {		
> 			case PROBLEM_CONNECTING: 
> 				System.out.println(osDeviceState.EnumgetRuntimeState());
> 				break; 
> 			case PROBLEM_SENDING:
> 				System.out.println(osDeviceState.EnumgetRuntimeState());
> 				break; 
> 			case CONNECTED:
> 				System.out.println(osDeviceState.EnumgetRuntimeState());
> 				break; 
> 			case INVALID:
> 				System.out.println(osDeviceState.EnumgetRuntimeState());
> 				break; 
> 			case INTERRUPTED:
> 				System.out.println(osDeviceState.EnumgetRuntimeState());
> 				break; 
> 			case STOPPED:
> 				System.out.println(osDeviceState.EnumgetRuntimeState());
> 				break; 
> 			default:
> 				System.out.println("Device state default is always ignored");			
> 				break;
> 		}
> 	}
> }
> HelperClass.java
> package entity;
> import org.jboss.cache.pojo.annotation.Replicable;
> import org.jboss.cache.pojo.annotation.Transient;
> @Replicable
> public class HelperClass {
> 	private RuntimeStateRange runtimeState = RuntimeStateRange.RESTING;
> 	
> 	public static enum RuntimeStateRange {
> 		OFFLINE, 
> 		CONNECTED, 
> 		PROBLEM, 
> 		PROBLEM_CONNECTING,
> 		PROBLEM_SENDING,
> 		INTERRUPTED,
> 		STOPPED,
> 		INVALID,
> 		RESTING,
> 		BUSY,
> 		INITIALIZING }; 
> 		
> 	public HelperClass() {
> 		System.out.println("HelperClass created.");
> 	}
> 	public int EnumgetRuntimeState() {
> 		return runtimeState.ordinal();
> 	}
> 	
> 	public RuntimeStateRange getRuntimeStateRange(){
> 		return runtimeState;
> 	}
> }
> <--------------------------END src --------------->
> <-------------------Stack trace ------------------>
> 15:09:15,730 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
> 15:09:15,730 INFO  [ServerImpl] Release ID: JBoss [The Oracle] 5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)
> 15:09:15,730 INFO  [ServerImpl] Bootstrap URL: null
> 15:09:15,730 INFO  [ServerImpl] Home Dir: C:\Java\jboss-5.1.0.GA
> 15:09:15,730 INFO  [ServerImpl] Home URL: file:/C:/Java/jboss-5.1.0.GA/
> 15:09:15,730 INFO  [ServerImpl] Library URL: file:/C:/Java/jboss-5.1.0.GA/lib/
> 15:09:15,730 INFO  [ServerImpl] Patch URL: null
> 15:09:15,730 INFO  [ServerImpl] Common Base URL: file:/C:/Java/jboss-5.1.0.GA/common/
> 15:09:15,746 INFO  [ServerImpl] Common Library URL: file:/C:/Java/jboss-5.1.0.GA/common/lib/
> 15:09:15,746 INFO  [ServerImpl] Server Name: all
> 15:09:15,746 INFO  [ServerImpl] Server Base Dir: C:\Java\jboss-5.1.0.GA\server
> 15:09:15,746 INFO  [ServerImpl] Server Base URL: file:/C:/Java/jboss-5.1.0.GA/server/
> 15:09:15,746 INFO  [ServerImpl] Server Config URL: file:/C:/Java/jboss-5.1.0.GA/server/all/conf/
> 15:09:15,746 INFO  [ServerImpl] Server Home Dir: C:\Java\jboss-5.1.0.GA\server\all
> 15:09:15,746 INFO  [ServerImpl] Server Home URL: file:/C:/Java/jboss-5.1.0.GA/server/all/
> 15:09:15,746 INFO  [ServerImpl] Server Data Dir: C:\Java\jboss-5.1.0.GA\server\all\data
> 15:09:15,746 INFO  [ServerImpl] Server Library URL: file:/C:/Java/jboss-5.1.0.GA/server/all/lib/
> 15:09:15,746 INFO  [ServerImpl] Server Log Dir: C:\Java\jboss-5.1.0.GA\server\all\log
> 15:09:15,746 INFO  [ServerImpl] Server Native Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp\native
> 15:09:15,746 INFO  [ServerImpl] Server Temp Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp
> 15:09:15,746 INFO  [ServerImpl] Server Temp Deploy Dir: C:\Java\jboss-5.1.0.GA\server\all\tmp\deploy
> 15:09:16,355 INFO  [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/Java/jboss-5.1.0.GA/server/all/conf/bootstrap.xml
> 15:09:16,886 INFO  [VFSCacheFactory] Initializing VFSCache [org.jboss.virtual.plugins.cache.CombinedVFSCache]
> 15:09:16,886 INFO  [VFSCacheFactory] Using VFSCache [CombinedVFSCache[real-cache: null]]
> 15:09:17,152 INFO  [CopyMechanism] VFS temp dir: C:\Java\jboss-5.1.0.GA\server\all\tmp
> 15:09:17,152 INFO  [ZipEntryContext] VFS force nested jars copy-mode is enabled.
> 15:09:18,043 INFO  [ServerInfo] Java version: 1.6.0_11,Sun Microsystems Inc.
> 15:09:18,043 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
> 15:09:18,043 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 11.0-b16,Sun Microsystems Inc.
> 15:09:18,043 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
> 15:09:18,043 INFO  [ServerInfo] VM arguments: -Djboss.home=C:/Java/jboss-5.1.0.GA -Djava.library.path=C:/Program Files/Java/jdk1.6.0_11/bin -Djava.endorsed.dirs=C:/Java/jboss-5.1.0.GA/lib/endorsed -Xms256m -Xmx512m -XX:MaxPermSize=256m -Djboss.partition.name=Wernie -Dfile.encoding=Cp1252 
> 15:09:18,105 INFO  [JMXKernel] Legacy JMX core initialized
> 15:09:19,652 INFO  [ProfileServiceBootstrap] Loading profile: ProfileKey at 453dd5[domain=default, server=default, name=all]
> 15:09:21,246 INFO  [WebService] Using RMI server codebase: http://HHDEV06:8083/
> 15:09:26,089 INFO  [NativeServerConfig] JBoss Web Services - Stack Native Core
> 15:09:26,089 INFO  [NativeServerConfig] 3.1.2.GA
> 15:09:26,886 INFO  [AttributeCallbackItem] Owner callback not implemented.
> 15:09:28,495 INFO  [LogNotificationListener] Adding notification listener for logging mbean "jboss.system:service=Logging,type=Log4jService" to server org.jboss.mx.server.MBeanServerImpl at 23d278[ defaultDomain='jboss' ]
> 15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
> 15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
> 15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
> 15:09:40,151 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 22212860{vfsfile:/C:/Java/jboss-5.1.0.GA/server/all/deploy/profileservice-secured.jar/}
> 15:09:40,182 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 1507654{vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/test_clustered_slsb.jar/}
> 15:09:40,182 INFO  [Ejb3DependenciesDeployer] Encountered deployment AbstractVFSDeploymentContext at 1507654{vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/test_clustered_slsb.jar/}
> 15:09:41,322 INFO  [CorbaNamingService] CORBA Naming Started
> 15:09:45,869 INFO  [JMXConnectorServerService] JMX Connector server: service:jmx:rmi://HHDEV06/jndi/rmi://HHDEV06:1090/jmxconnector
> 15:09:46,103 INFO  [MailService] Mail Service bound to java:/Mail
> 15:09:46,681 INFO  [SnmpAgentService] SNMP agent going active
> 15:09:49,166 INFO  [Wernie] Initializing partition Wernie
> 15:09:49,291 INFO  [STDOUT] 
> ---------------------------------------------------------
> GMS: address is 192.168.100.98:2335 (cluster=Wernie)
> ---------------------------------------------------------
> 15:09:49,416 INFO  [PlatformMBeanServerRegistration] JBossCache MBeans were successfully registered to the platform mbean server.
> 15:09:49,447 INFO  [STDOUT] 
> ---------------------------------------------------------
> GMS: address is 192.168.100.98:2335 (cluster=Wernie-HAPartitionCache)
> ---------------------------------------------------------
> 15:09:51,369 INFO  [Wernie] Number of cluster members: 1
> 15:09:51,384 INFO  [Wernie] Other members: 0
> 15:09:51,462 INFO  [RPCManagerImpl] Received new cluster view: [192.168.100.98:2335|0] [192.168.100.98:2335]
> 15:09:51,462 INFO  [RPCManagerImpl] Cache local address is 192.168.100.98:2335
> 15:09:51,462 INFO  [RPCManagerImpl] state was retrieved successfully (in 2,02 seconds)
> 15:09:51,478 INFO  [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA
> 15:09:51,478 INFO  [Wernie] Fetching serviceState (will wait for 30000 milliseconds):
> 15:09:51,478 INFO  [Wernie] State could not be retrieved (we are the first member in group)
> 15:09:51,556 INFO  [HANamingService] Started HAJNDI bootstrap; jnpPort=1100, backlog=50, bindAddress=/0.0.0.0
> 15:09:51,572 INFO  [DetachedHANamingService$AutomaticDiscovery] Listening on /0.0.0.0:1102, group=230.0.0.4, HA-JNDI address=192.168.100.98:1100
> 15:09:52,494 INFO  [UnifiedInvokerHA] Service name is jboss:service=invoker,type=unifiedha
> 15:09:53,040 WARN  [JBossASSecurityMetadataStore] WARNING! POTENTIAL SECURITY RISK. It has been detected that the MessageSucker component which sucks messages from one node to another has not had its password changed from the installation default. Please see the JBoss Messaging user guide for instructions on how to do this.
> 15:09:53,072 WARN  [AnnotationCreator] No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
> 15:09:53,212 WARN  [AnnotationCreator] No ClassLoader provided, using TCCL: org.jboss.managed.api.annotation.ManagementComponent
> 15:09:53,290 INFO  [TransactionManagerService] JBossTS Transaction Service (JTA version - tag:JBOSSTS_4_6_1_GA) - JBoss Inc.
> 15:09:53,290 INFO  [TransactionManagerService] Setting up property manager MBean and JMX layer
> 15:09:54,337 INFO  [TransactionManagerService] Initializing recovery manager
> 15:09:54,478 INFO  [TransactionManagerService] Recovery manager configured
> 15:09:54,478 INFO  [TransactionManagerService] Binding TransactionManager JNDI Reference
> 15:09:54,525 INFO  [TransactionManagerService] Starting transaction recovery manager
> 15:09:55,025 INFO  [AprLifecycleListener] The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:/Program Files/Java/jdk1.6.0_11/bin
> 15:09:55,087 INFO  [Http11Protocol] Initializing Coyote HTTP/1.1 on http-0.0.0.0-8080
> 15:09:55,087 INFO  [AjpProtocol] Initializing Coyote AJP/1.3 on ajp-0.0.0.0-8009
> 15:09:55,103 INFO  [StandardService] Starting service jboss.web
> 15:09:55,118 INFO  [StandardEngine] Starting Servlet Engine: JBoss Web/2.1.3.GA
> 15:09:55,181 INFO  [Catalina] Server startup in 91 ms
> 15:09:55,197 INFO  [TomcatDeployment] deploy, ctxPath=/juddi
> 15:09:55,743 INFO  [RegistryServlet] Loading jUDDI configuration.
> 15:09:55,743 INFO  [RegistryServlet] Resources loaded from: /WEB-INF/juddi.properties
> 15:09:55,743 INFO  [RegistryServlet] Initializing jUDDI components.
> 15:09:55,962 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
> 15:09:56,009 INFO  [TomcatDeployment] deploy, ctxPath=/web-console
> 15:09:57,462 INFO  [TomcatDeployment] deploy, ctxPath=/jbossws
> 15:09:57,618 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jboss-local-jdbc.rar/META-INF/ra.xml
> 15:09:57,634 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jboss-xa-jdbc.rar/META-INF/ra.xml
> 15:09:57,665 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/jms-ra.rar/META-INF/ra.xml
> 15:09:57,696 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/mail-ra.rar/META-INF/ra.xml
> 15:09:57,712 INFO  [RARDeployment] Required license terms exist, view vfszip:/C:/Java/jboss-5.1.0.GA/server/all/deploy/quartz-ra.rar/META-INF/ra.xml
> 15:09:57,806 INFO  [SimpleThreadPool] Job execution threads will use class loader of thread: main
> 15:09:57,853 INFO  [QuartzScheduler] Quartz Scheduler v.1.5.2 created.
> 15:09:57,853 INFO  [RAMJobStore] RAMJobStore initialized.
> 15:09:57,853 INFO  [StdSchedulerFactory] Quartz scheduler 'DefaultQuartzScheduler' initialized from default resource file in Quartz package: 'quartz.properties'
> 15:09:57,853 INFO  [StdSchedulerFactory] Quartz scheduler version: 1.5.2
> 15:09:57,853 INFO  [QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
> 15:09:58,368 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
> 15:09:58,915 INFO  [ServerPeer] JBoss Messaging 1.4.3.GA server [0] started
> 15:09:59,134 INFO  [STDOUT] 
> ---------------------------------------------------------
> GMS: address is 192.168.100.98:2335 (cluster=MessagingPostOffice-CTRL)
> ---------------------------------------------------------
> 15:10:01,149 INFO  [GroupMember] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 52bb2d got new view [192.168.100.98:2335|0] [192.168.100.98:2335], old view is null
> 15:10:01,149 INFO  [GroupMember] I am (192.168.100.98:2335)
> 15:10:01,149 INFO  [GroupMember] New Members : 1 ([192.168.100.98:2335])
> 15:10:01,149 INFO  [GroupMember] All Members : 1 ([192.168.100.98:2335])
> 15:10:01,181 INFO  [STDOUT] 
> ---------------------------------------------------------
> GMS: address is 192.168.100.98:7900 (cluster=MessagingPostOffice-DATA)
> ---------------------------------------------------------
> 15:10:07,227 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
> 15:10:07,227 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at bfd4f6 started
> 15:10:07,258 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
> 15:10:07,258 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at 1c977ef started
> 15:10:07,274 INFO  [QueueService] Queue[/queue/DLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
> 15:10:07,305 INFO  [ConnectionFactory] Connector bisocket://HHDEV06:4457 has leasing enabled, lease period 10000 milliseconds
> 15:10:07,305 INFO  [ConnectionFactory] org.jboss.jms.server.connectionfactory.ConnectionFactory at 14647e5 started
> 15:10:07,305 INFO  [QueueService] Queue[/queue/ExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
> 15:10:07,461 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'
> 15:10:07,883 INFO  [JBossASKernel] Created KernelDeployment for: profileservice-secured.jar
> 15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3
> 15:10:07,883 INFO  [JBossASKernel]   with dependencies:
> 15:10:07,883 INFO  [JBossASKernel]   and demands:
> 15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView
> 15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
> 15:10:07,883 INFO  [JBossASKernel]   and supplies:
> 15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.profileservice.spi.ProfileService
> 15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureProfileService/remote
> 15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureProfileService/remote-org.jboss.profileservice.spi.ProfileService
> 15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3) to KernelDeployment of: profileservice-secured.jar
> 15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3
> 15:10:07,883 INFO  [JBossASKernel]   with dependencies:
> 15:10:07,883 INFO  [JBossASKernel]   and demands:
> 15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
> 15:10:07,883 INFO  [JBossASKernel]   and supplies:
> 15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureDeploymentManager/remote-org.jboss.deployers.spi.management.deploy.DeploymentManager
> 15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.deployers.spi.management.deploy.DeploymentManager
> 15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureDeploymentManager/remote
> 15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3) to KernelDeployment of: profileservice-secured.jar
> 15:10:07,883 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3
> 15:10:07,883 INFO  [JBossASKernel]   with dependencies:
> 15:10:07,883 INFO  [JBossASKernel]   and demands:
> 15:10:07,883 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
> 15:10:07,883 INFO  [JBossASKernel]   and supplies:
> 15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView
> 15:10:07,883 INFO  [JBossASKernel] 	Class:org.jboss.deployers.spi.management.ManagementView
> 15:10:07,883 INFO  [JBossASKernel] 	jndi:SecureManagementView/remote
> 15:10:07,883 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3) to KernelDeployment of: profileservice-secured.jar
> 15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at f5f77{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
> 15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 1bd9f3d{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
> 15:10:07,899 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at 98fc6a{name=jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
> 15:10:08,024 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureDeploymentManager,service=EJB3
> 15:10:08,039 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureDeploymentManager ejbName: SecureDeploymentManager
> 15:10:08,102 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:
> 	SecureDeploymentManager/remote - EJB3.x Default Remote Business Interface
> 	SecureDeploymentManager/remote-org.jboss.deployers.spi.management.deploy.DeploymentManager - EJB3.x Remote Business Interface
> 15:10:08,196 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureManagementView,service=EJB3
> 15:10:08,196 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureManagementView ejbName: SecureManagementView
> 15:10:08,211 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:
> 	SecureManagementView/remote - EJB3.x Default Remote Business Interface
> 	SecureManagementView/remote-org.jboss.deployers.spi.management.ManagementView - EJB3.x Remote Business Interface
> 15:10:08,274 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=profileservice-secured.jar,name=SecureProfileService,service=EJB3
> 15:10:08,274 INFO  [EJBContainer] STARTED EJB: org.jboss.profileservice.ejb.SecureProfileServiceBean ejbName: SecureProfileService
> 15:10:08,305 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:
> 	SecureProfileService/remote - EJB3.x Default Remote Business Interface
> 	SecureProfileService/remote-org.jboss.profileservice.spi.ProfileService - EJB3.x Remote Business Interface
> 15:10:08,414 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3
> 15:10:08,414 INFO  [JBossASKernel]   with dependencies:
> 15:10:08,414 INFO  [JBossASKernel]   and demands:
> 15:10:08,414 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
> 15:10:08,414 INFO  [JBossASKernel]   and supplies:
> 15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local
> 15:10:08,414 INFO  [JBossASKernel] 	Class:service.ITestServiceBeanManagement
> 15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/remote
> 15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
> 15:10:08,414 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3) to KernelDeployment of: test_clustered_slsb.jar
> 15:10:08,414 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3
> 15:10:08,414 INFO  [JBossASKernel]   with dependencies:
> 15:10:08,414 INFO  [JBossASKernel]   and demands:
> 15:10:08,414 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
> 15:10:08,414 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
> 15:10:08,414 INFO  [JBossASKernel]   and supplies:
> 15:10:08,414 INFO  [JBossASKernel] 	jndi:TestClusteredBean/remote
> 15:10:08,414 INFO  [JBossASKernel] 	Class:session.ITestClusteredBean
> 15:10:08,414 INFO  [JBossASKernel] 	jndi:TestClusteredBean/remote-session.ITestClusteredBean
> 15:10:08,414 INFO  [JBossASKernel] Added bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3) to KernelDeployment of: test_clustered_slsb.jar
> 15:10:08,414 INFO  [EJB3EndpointDeployer] Deploy AbstractBeanMetaData at ad588a{name=jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3_endpoint bean=org.jboss.ejb3.endpoint.deployers.impl.EndpointImpl properties=[container] constructor=null autowireCandidate=true}
> 15:10:08,602 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
> 15:10:08,618 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
> 15:10:08,649 INFO  [PlatformMBeanServerRegistration] JBossCache MBeans were successfully registered to the platform mbean server.
> 15:10:08,711 INFO  [STDOUT] 
> ---------------------------------------------------------
> GMS: address is 192.168.100.98:2353 (cluster=Wernie-UnistreamPojoCache)
> ---------------------------------------------------------
> 15:10:10,774 INFO  [RPCManagerImpl] Received new cluster view: [192.168.100.98:2353|0] [192.168.100.98:2353]
> 15:10:10,774 INFO  [RPCManagerImpl] Cache local address is 192.168.100.98:2353
> 15:10:10,774 INFO  [RPCManagerImpl] state was retrieved successfully (in 2,11 seconds)
> 15:10:10,774 INFO  [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA
> 15:10:10,930 INFO  [JBossASKernel] installing bean: jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3,type=ManagementInterface
> 15:10:10,930 INFO  [JBossASKernel]   with dependencies:
> 15:10:10,930 INFO  [JBossASKernel]   and demands:
> 15:10:10,930 INFO  [JBossASKernel] 	jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3
> 15:10:10,930 INFO  [JBossASKernel] 	jboss.ejb:service=EJBTimerService
> 15:10:10,930 INFO  [JBossASKernel]   and supplies:
> 15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/local
> 15:10:10,930 INFO  [JBossASKernel] 	Class:service.ITestServiceBeanManagement
> 15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/remote
> 15:10:10,930 INFO  [JBossASKernel] 	jndi:TestServiceBean/local-service.ITestServiceBeanLocal
> 15:10:10,930 INFO  [JBossASKernel] Installing bean(jboss.j2ee:jar=test_clustered_slsb.jar,name=TestServiceBean,service=EJB3,type=ManagementInterface) into kernel
> 15:10:10,961 WARN  [UniStreamCacheListener] ::::  UniStreamCacheListener created  ::::
> 15:10:10,961 INFO  [PojoCacheImpl] PojoCache version: JBossCache 'Cascabel' 3.1.0.GA
> 15:10:10,961 INFO  [STDOUT] Create of TestServiceBean
> 15:10:10,961 INFO  [EJBContainer] STARTED EJB: service.TestServiceBean ejbName: TestServiceBean
> 15:10:10,977 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:
> 	TestServiceBean/local - EJB3.x Default Local Business Interface
> 	TestServiceBean/local-service.ITestServiceBeanLocal - EJB3.x Local Business Interface
> 15:10:11,024 INFO  [SessionSpecContainer] Starting jboss.j2ee:jar=test_clustered_slsb.jar,name=TestClusteredBean,service=EJB3
> 15:10:11,024 INFO  [EJBContainer] STARTED EJB: session.TestClusteredBean ejbName: TestClusteredBean
> 15:10:11,071 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:
> 	TestClusteredBean/remote - EJB3.x Default Remote Business Interface
> 	TestClusteredBean/remote-session.ITestClusteredBean - EJB3.x Remote Business Interface
> 15:10:11,102 INFO  [PersistenceUnitDeployment] Starting persistence unit persistence.unit:unitName=#unistream
> 15:10:11,196 INFO  [Version] Hibernate Annotations 3.4.0.GA
> 15:10:11,227 INFO  [Environment] Hibernate 3.3.1.GA
> 15:10:11,242 INFO  [Environment] hibernate.properties not found
> 15:10:11,242 INFO  [Environment] Bytecode provider name : javassist
> 15:10:11,242 INFO  [Environment] using JDK 1.4 java.sql.Timestamp handling
> 15:10:11,383 INFO  [Version] Hibernate Commons Annotations 3.1.0.GA
> 15:10:11,383 INFO  [Version] Hibernate EntityManager 3.4.0.GA
> 15:10:11,430 INFO  [Ejb3Configuration] Processing PersistenceUnitInfo [
> 	name: unistream
> 	...]
> 15:10:11,461 WARN  [Ejb3Configuration] Persistence provider caller does not implement the EJB3 spec correctly. PersistenceUnitInfo.getNewTempClassLoader() is null.
> 15:10:11,570 INFO  [AnnotationBinder] Binding entity from annotated class: entity.Request
> 15:10:11,664 INFO  [EntityBinder] Bind entity entity.Request on table Request
> 15:10:11,680 ERROR [AbstractKernelController] Error installing to Start: name=persistence.unit:unitName=#unistream state=Create
> java.lang.VerifyError: (class: entity/Request, method: informDeviceStateWhileHavingFullLock signature: (Lentity/HelperClass;)V) Unable to pop operand off an empty stack
> 	at java.lang.Class.getDeclaredMethods0(Native Method)
> 	at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
> 	at java.lang.Class.getDeclaredMethods(Class.java:1791)
> 	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredMethodProperties(JavaXClass.java:89)
> 	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredProperties(JavaXClass.java:106)
> 	at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredProperties(JavaXClass.java:98)
> 	at org.hibernate.cfg.AnnotationBinder.addElementsOfAClass(AnnotationBinder.java:1023)
> 	at org.hibernate.cfg.AnnotationBinder.getElementsToProcess(AnnotationBinder.java:859)
> 	at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:667)
> 	at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:546)
> 	at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:291)
> 	at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1148)
> 	at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1226)
> 	at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:173)
> 	at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:854)
> 	at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:425)
> 	at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:131)
> 	at org.jboss.jpa.deployment.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:301)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
> 	at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
> 	at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> 	at org.jboss.Main.boot(Main.java:221)
> 	at org.jboss.Main$1.run(Main.java:556)
> 	at java.lang.Thread.run(Thread.java:619)
> 15:10:11,774 INFO  [TomcatDeployment] deploy, ctxPath=/admin-console
> 15:10:11,852 INFO  [config] Initializing Mojarra (1.2_12-b01-FCS) for context '/admin-console'
> 15:10:15,680 INFO  [TomcatDeployment] deploy, ctxPath=/
> 15:10:15,726 INFO  [TomcatDeployment] deploy, ctxPath=/jmx-console
> 15:10:15,883 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> DEPLOYMENTS IN ERROR:
>   Deployment "persistence.unit:unitName=#unistream" is in error due to the following reason(s): java.lang.VerifyError: (class: entity/Request, method: informDeviceStateWhileHavingFullLock signature: (Lentity/HelperClass;)V) Unable to pop operand off an empty stack
> 15:10:15,883 INFO  [Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8080
> 15:10:15,914 INFO  [AjpProtocol] Starting Coyote AJP/1.3 on ajp-0.0.0.0-8009
> 15:10:15,930 INFO  [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 1m:184ms
> <----------------------END Stack trace ----------------------->
> <----------------------- Ant file ------------------------->
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <!DOCTYPE project [
> 	<!ENTITY properties SYSTEM "../../../unispool7/config/buildfiles/properties.xml">
> ]>
> <project default="deploy2Jboss" name="TestClusteredSessionBean" basedir="../..">
> 	<!-- read the properties from file -->
> 	&properties;
> 	<target name="prepare">
> 		<path id="classpath">
> 			<path refid="jboss.aop.classpath"/>
> 			<path refid="jboss.class.path"/>
> 			<pathelement path="bin"/>
> 		</path>
> 	</target>
> 	<target name="compile" depends="prepare">
> 		<delete dir="bin"/>
> 		<mkdir dir="bin"/>
> 		<javac srcdir="src" destdir="bin" deprecation="on" optimize="off" includes="**">
> 			<classpath refid="classpath"/>
> 		</javac>
> 		<copy todir="bin" filtering="no">
> 			<fileset dir="config/properties">
> 				<include name="**/*.properties"/>
> 			</fileset>
> 			<fileset dir="config">
> 				<include name="**/persistence.xml"/>
> 				<include name="**/unistream-pojo-cache-jboss-beans.xml"/>
> 			</fileset>
> 		</copy>
> 	</target>
> 	<target name="aopc" depends="compile">
> 		<unjar src="${jbossServerLib}/jbosscache-pojo.jar" dest="bin">
> 			<mapper type="flatten"/>
> 			<patternset>
>         		<include name="**/pojocache-aop.xml"/>
>     		</patternset>
> 		</unjar>
> 		<aopc compilerclasspathref="classpath" classpathref="classpath" verbose="true">
> 			<classpath path="bin"/>
> 			<src path="bin"/>
> 			<aoppath path="bin/pojocache-aop.xml"/>
> 			<aopclasspath path="bin"/>
> 		</aopc>
> 	</target>
> 	<target name="package-server-jar" depends="aopc" description="Create JAR File">
> 		<jar destfile="build/test_clustered_slsb.jar">
> 			<fileset dir="bin">
>                 <include name="**/*.*"/>
>                 <exclude name="**/Main.*"/>
>                 <exclude name="**/jndi.properties"/>
>                 <exclude name="**/pojocache-aop.xml"/>
> 			</fileset>
> 		</jar>
> 	</target>
> 	<target name="run-compile-time" depends="aopc">
> 		<java fork="yes" failOnError="true" className="Main">
> 			<sysproperty key="jboss.aop.path" value="bin/pojocache-aop.xml"/>
> 			<sysproperty key="jboss.aop.class.path" value="bin"/>
> 			<classpath refid="classpath"/>
> 		</java>
> 	</target>
> 	
> 	<target name="deploy2Jboss" depends="package-server-jar" description="Deploy the JAR File to JBoss">
> 		<copy file="build/test_clustered_slsb.jar" tofile="C:\Java\jboss-5.1.0.GA\server\all\deploy\test_clustered_slsb.jar"/>
> 	</target>
> </project>
> The properties file used by ant:
> <!-- Read in the environment variables -->
> <property environment="env"/>
> <!-- Inits the properties -->
> <tstamp/>
> <!-- needed for if, switch tasks -->
> <taskdef resource="net/sf/antcontrib/antcontrib.properties"/>
> <taskdef resource="net/sf/antcontrib/antlib.xml"/>
> <!-- base directories -->
> <property name="src" location="${basedir}/src"/>
> <property name="conf" location="${basedir}/config"/>
> <property name="build" location="${basedir}/build"/>
> <property name="dist" location="${basedir}/dist"/>
> <property name="dist-obfuscated" location="${basedir}/dist-obfuscated"/>
> <property name="ext" location="${basedir}/ext"/>
> <property name="app" value="com/hollandhouse/unistream"/>
> <!-- src directories -->
> <property name="src" location="${src}"/>
> <property name="HhLog4j" location="${src}/com/hollandhouse/unistream/framework/log/log4j/"/>
> <!-- conf directories -->
> <property name="conf-xml" location="${conf}/XML"/>
> <property name="conf-jboss" location="${conf}/JBoss"/>
> <property name="conf-properties" location="${conf}/properties"/>
> <property name="conf-properties-server" location="${conf-properties}/server"/>
> <property name="conf-properties-agent" location="${conf-properties}/agent"/>
> <property name="conf-mergefiles" location="${conf}/mergefiles"/>
> <property name="conf-buildfiles" location="${conf}/buildfiles"/>
> <property name="conf-cache" location="${conf}/cache"/>
> <!-- build directories -->
> <property name="build-generated" location="${build}/generated"/>
> <property name="generated.java.dir" value="${build-generated}"/>
> <property name="build-classes" location="${build}/classes"/>
> <property name="build-resources" location="${build}/resources"/>
> <property name="build-doc" location="${build}/doc"/>
> <property name="build-web" location="${build}/web"/>
> <!-- file names -->
> <property name="ejb-file" value="unistream-ejb3.jar"/>
> <property name="ejb-agent-file" value="unistream-agent.jar"/>
> <property name="sar-file" value="unistream.sar"/>
> <property name="sar-agent-file" value="unistream-agent.sar"/>
> <property name="entities-jar-file" value="entities.jar"/>
> <property name="jar-entities-agent-file" value="entities-agent.jar"/>
> <property name="war-file" value="unistream.war"/>
> <property name="jar-hhlog4j-file" value="hhlog4j.jar"/>
> <property name="xml-hhlog4j-file" value="log4j_unistream.xml"/>
> <property name="common-file" value="unistream-framework.jar"/>
> <property name="cli-file" value="unistream-cli.jar"/>
> <property name="ear-file" value="unistream.ear"/>
> <property name="ear-agent-file" value="unistream-agent.ear"/>
> <property name="swing-gui-file" value="unistream-swing-gui.jar"/>
> <property name="swing-gui-doc-file" value="unistream-swing-gui-doc.zip"/>
> <property name="testpage-file" value="UNISTREAM-TESTFILE"/>
> <property name="usPojoCache-file" value="unistream-pojo-cache-jboss-beans.xml"/>
> <!-- build test directories -->
> <property name="build-tests" location="${build}/tests"/>
> <property name="build-reports" location="${build}/reports"/>
> <!-- jboss settings main -->
> <property name="jbossServerProfile" value="unistream_main"/>
> <property name="jbossServer" location="${env.JBOSS_HOME}/server/${jbossServerProfile}"/>
> <property name="jbossDeploy" location="${jbossServer}/deploy"/>
> <property name="jbossServerLib" location="${jbossServer}/lib"/>
> <property name="jbossConfig" location="${jbossServer}/conf"/>
> <!-- jboss settings agent -->
> <property name="jbossAgentProfile" value="unistream_agent"/>
> <property name="jbossAgent" location="${env.JBOSS_HOME}/server/${jbossAgentProfile}"/>
> <property name="jbossAgentDeploy" location="${jbossAgent}/deploy"/>
> <property name="jbossAgentLib" location="${jbossAgent}/lib"/>
> <property name="jbossAgentConfig" location="${jbossAgent}/conf"/>
> <!-- jboss settings common -->
> <property name="jbossLib" location="${env.JBOSS_HOME}/lib"/>
> <property name="jbossClientLib" value="${env.JBOSS_HOME}/client"/>
> <property name="jbossCommonLib" location="${env.JBOSS_HOME}/common/lib"/>
> <!--        <property name="jbossDataSource" value="java:/mysqlDS"/>
> <property name="jbossDataSourceMapping" value="mySQL"/> -->
> <property name="jbossDataSource" value="java:/DefaultDS"/>
> <property name="jbossDataSourceMapping" value="Hypersonic SQL"/>
> <!-- Temp General manifest file -->
> <property name="manifest-general" location="${build}/manifest_gen.txt"/>
> <!-- Temp ClassPath manifest file -->
> <property name="manifest-classpath" location="${build}/manifest_cp.txt"/>
> <property name="version-file" value="unistream-version"/>
> <!--  jboss properties files -->
> <property name="xml-hhlog4j-path" location="${conf-properties-server}/${xml-hhlog4j-file}"/>
> <property name="xml-hhlog4j-agent-path" location="${conf-properties-agent}/${xml-hhlog4j-file}"/>
> <!-- setup the project class paths -->
> <path id="jboss.class.path">
> 	<fileset dir="${jbossLib}">
> 		<include name="*.jar"/>
> 	</fileset>
> 	<fileset dir="${env.JBOSS_HOME}/client">
> 		<include name="*.jar"/>
> 	</fileset>
> 	<fileset dir="${jbossCommonLib}">
> 		<include name="*.jar"/>
> 	</fileset>
> 	<fileset dir="${jbossServerLib}">
> 		<include name="*.jar"/>
> 	</fileset>
> </path>
> <path id="ext.class.path">
> 	<path refid="jboss.class.path"/>
> 	<fileset dir="${ext}">
> 		<include name="**/*.jar"/>
> 	</fileset>
> </path>
> <path id="jboss.aop.classpath">
> 	<fileset dir="${jbossLib}">
> 		<include name="jboss-aop.jar"/>
> 	</fileset>
> </path>
> <!-- setup the project class paths -->
> <path id="project.class.path">
> 	<path refid="ext.class.path"/>
> 	<path refid="jboss.aop.classpath"/>
> </path>
> <!-- Define the JBoss AOP compiler Ant task -->
> <taskdef name="aopc" classname="org.jboss.aop.ant.AopC" classpathref="jboss.aop.classpath"/>
> <path id="junit.test.class.path">
> 	<path refid="ext.class.path"/>
> 	<fileset dir="${dist}">
> 		<include name="*.jar"/>
> 		<include name="*.sar"/>
> 		<exclude name="*-agent.*"/>
> 	</fileset>
> 	<pathelement location="${conf-properties}"/>
> 	<pathelement location="${build-classes}"/>
> </path>
> <!-- Project Libraries -->
> <property name="gui-jar-path" value="${basedir}/unistreamgui.jar"/>
> <path id="library.gui_jars.classpath">
> 	<pathelement location="${jbossClientLib}/commons-logging.jar"/>
> 	<pathelement location="${jbossClientLib}/concurrent.jar"/>
> 	<pathelement location="${jbossClientLib}/ejb3-persistence.jar"/>
> 	<pathelement location="${jbossClientLib}/hibernate-annotations.jar"/>
> 	<pathelement location="${jbossClientLib}/javassist.jar"/>
> 	<pathelement location="${jbossClientLib}/jbossall-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-aop-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-aspect-jdk50-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-common-core.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-ejb3-common-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-ejb3-core-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-ejb3-ext-api.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-ejb3-ext-api-impl.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-ejb3-proxy-impl-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-ejb3-proxy-spi-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-ejb3-security-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-integration.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-javaee.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-logging-log4j.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-logging-spi.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-mdr.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-messaging-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-remoting.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-security-spi.jar"/>
> 	<pathelement location="${jbossClientLib}/jboss-serialization.jar"/>
> 	<pathelement location="${jbossClientLib}/jbosssx-client.jar"/>
> 	<pathelement location="${jbossClientLib}/jnp-client.jar"/>
> 	<pathelement location="${jbossClientLib}/log4j.jar"/>
> 	<pathelement location="${jbossClientLib}/trove.jar"/>
> 	<pathelement location="${jbossCommonLib}/hibernate-core.jar"/>
> </path>
> <path id="library.javahelp.classpath">
> 	<pathelement location="${basedir}/jars/java help/jh2.0/javahelp/lib/jh.jar"/>
> </path>
> <!-- Global Libraries -->
> <path id="library.junit.classpath">
> 	<pathelement location="${basedir}/jars/junit-4.0/junit-4.0.jar"/>
> </path>
> <----------------------END Ant file -------------->

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 07:48:29 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Mon, 20 Jul 2009 07:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7109) Change log4j to
	2.1.15
Message-ID: <280657959.1248090509229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Change log4j to 2.1.15
----------------------

                 Key: JBAS-7109
                 URL: https://jira.jboss.org/jira/browse/JBAS-7109
             Project: JBoss Application Server
          Issue Type: Thirdparty Change
      Security Level: Public (Everyone can see)
          Components: Logging
    Affects Versions: JBossAS-5.1.0.GA
         Environment: jdk1.6u13
            Reporter: Ondrej Medek
            Assignee: David Lloyd


Apache log4j 1.2.15 is already 2 yrs released. Pls, use this version.

I like log4j 2.1.15 especially beacause of https://issues.apache.org/bugzilla/show_bug.cgi?id=32572

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 07:56:29 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Mon, 20 Jul 2009 07:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7109) Change log4j to
	1.2.15
In-Reply-To: <280657959.1248090509229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1341987220.1248090989404.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Medek updated JBAS-7109:
-------------------------------

        Summary: Change log4j to 1.2.15  (was: Change log4j to 2.1.15)
    Description: 
Apache log4j 1.2.15 is already 2 yrs released, but JBoss still uses 2.1.14.


I like log4j 1.2.15 especially because of https://issues.apache.org/bugzilla/show_bug.cgi?id=32572

  was:
Apache log4j 1.2.15 is already 2 yrs released, but JBoss still uses 2.1.14.


I like log4j 2.1.15 especially because of https://issues.apache.org/bugzilla/show_bug.cgi?id=32572



> Change log4j to 1.2.15
> ----------------------
>
>                 Key: JBAS-7109
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7109
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: jdk1.6u13
>            Reporter: Ondrej Medek
>            Assignee: David Lloyd
>
> Apache log4j 1.2.15 is already 2 yrs released, but JBoss still uses 2.1.14.
> I like log4j 1.2.15 especially because of https://issues.apache.org/bugzilla/show_bug.cgi?id=32572

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 07:56:29 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Mon, 20 Jul 2009 07:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7109) Change log4j to 1.2.15
In-Reply-To: <280657959.1248090509229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1940652042.1248090989518.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Medek closed JBAS-7109.
------------------------------

    Resolution: Duplicate Issue


This bug duplicates https://jira.jboss.org/jira/browse/JBAS-4974

> Change log4j to 1.2.15
> ----------------------
>
>                 Key: JBAS-7109
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7109
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: jdk1.6u13
>            Reporter: Ondrej Medek
>            Assignee: David Lloyd
>
> Apache log4j 1.2.15 is already 2 yrs released, but JBoss still uses 2.1.14.
> I like log4j 1.2.15 especially because of https://issues.apache.org/bugzilla/show_bug.cgi?id=32572

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 07:10:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 20 Jul 2009 07:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1605) management API
 needs a portable and complete serialization format
In-Reply-To: <1388356.1240496381566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2077817462.1248088229490.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1605.
------------------------------------

    Resolution: Done


fixed in the trunk

> management API needs a portable and complete serialization format
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-1605
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1605
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>         Attachments: patch-JBMESSAGING-1605.txt
>
>
> to work in a replicated environment; JBoss Messaging needs a Management API which requires complex parameter. E.g.
> public void createConnectionFactory(String name,
>                                        List<Pair<TransportConfiguration, TransportConfiguration>> connectorConfigs,
>                                        String connectionLoadBalancingPolicyClassName,
>                                        long pingPeriod,
>                                        ...);
> TransportConfiguration also contains a Map<String, Object> of parameters.
> Currently, the management code does not allow for such complex API. It only works with simple types (primitives + Strings) and String[].
> Moreover, the management API returns results (attribute values or operations results) serialized using Java serialization which won't be portable on other platforms.
> We need to define a encoding format for Management API that allow complex parameters and be portable.
> One idea'd be to use JSON[1] for that (JSON for Java is 7 classes[2] we could import in JBM source code).
> With that, the management operations would be composed of a JSON string containing:
> - the name of the resource
> - the name of the operation
> - an orderded list of the parameters (as complex as they are)
> When JBM receives a management operations, it must decode the JSON strings and find the relevant methods to call.
> There is an issue here, JSON does not contain any information on the types of parameters.
> One solution is to add the parameter type in the JSON string (e.g. this JSON object can be decoded as a TransportConfiguration class) but it add extra burden on the client sending the message and is not well suited for portability reason.
> Another solution would be to add an additional layer on the server side.
> When a management message is received, we extract the name of the resource, the operation name and the number of parameters of the operation.
> We'd have a mapper which will know based on this information what method should be called on the resource and cast the parameters from JSON to the appropriate types (e.g. Boolean, String, int but also TransportConfiguration).
> The only constraint this solution have is that there must not be 2 methods on the same resource, with the same name and the same number of parameters. The cardinality of the methods must differ to be able to identify it uniquely. If the methods have the same numbers of parameters, they must have different names (e.g. createConnectionFactoryWithDiscoveryGroup() vs. createConnectionFactory() which takes a List of Pair of TransportConfiguration)
> For return type, we could return a JSON String containing the result. This would allow for complex results (similar to CompositeData and TabularData from JMX).
> [1] http://www.json.org/
> [2] http://www.json.org/java

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 07:58:29 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Mon, 20 Jul 2009 07:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-4974) Upgrade to log4j
 1.2.15 in JBoss5.0
In-Reply-To: <9052822.1195095618615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <615751299.1248091109382.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-4974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476840#action_12476840 ] 

Ondrej Medek commented on JBAS-4974:
------------------------------------

I would like finer SMTP configuration in 1.2.15.

> Upgrade to log4j 1.2.15 in JBoss5.0
> -----------------------------------
>
>                 Key: JBAS-4974
>                 URL: https://jira.jboss.org/jira/browse/JBAS-4974
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.0.0.Beta2
>            Reporter: cheng dan
>            Assignee: Scott M Stark
>            Priority: Minor
>
> Please upgrade to the latest stable log4j release 1.2.15 in JBoss5.0
> http://logging.apache.org/log4j/1.2/download.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 07:50:29 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Mon, 20 Jul 2009 07:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7109) Change log4j to
	2.1.15
In-Reply-To: <280657959.1248090509229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1697354141.1248090629236.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Medek updated JBAS-7109:
-------------------------------

    Description: 
Apache log4j 1.2.15 is already 2 yrs released, but JBoss still uses 2.1.14.


I like log4j 2.1.15 especially because of https://issues.apache.org/bugzilla/show_bug.cgi?id=32572

  was:
Apache log4j 1.2.15 is already 2 yrs released. Pls, use this version.

I like log4j 2.1.15 especially beacause of https://issues.apache.org/bugzilla/show_bug.cgi?id=32572

     Complexity: Low
         Labels: logging  (was: )


> Change log4j to 2.1.15
> ----------------------
>
>                 Key: JBAS-7109
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7109
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: jdk1.6u13
>            Reporter: Ondrej Medek
>            Assignee: David Lloyd
>
> Apache log4j 1.2.15 is already 2 yrs released, but JBoss still uses 2.1.14.
> I like log4j 2.1.15 especially because of https://issues.apache.org/bugzilla/show_bug.cgi?id=32572

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 18 08:58:29 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 18 Jul 2009 08:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2212) Rename Finish
 interface to Termination.
In-Reply-To: <2113079936.1247918909237.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2015793636.1247921909574.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet resolved JBRULES-2212.
---------------------------------------

    Resolution: Done


> Rename Finish interface to Termination.
> ---------------------------------------
>
>                 Key: JBRULES-2212
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2212
>             Project: JBoss Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>             Fix For: 5.1.0.M1
>
>
> Termination is more correct if you take a look at articles etc.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 18 08:08:29 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 18 Jul 2009 08:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2212) Rename Finish
 interface to Termination.
Message-ID: <2113079936.1247918909237.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Rename Finish interface to Termination.
---------------------------------------

                 Key: JBRULES-2212
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2212
             Project: JBoss Drools
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: drools-solver
    Affects Versions: 5.0.1.FINAL
            Reporter: Geoffrey De Smet
            Assignee: Geoffrey De Smet
             Fix For: 5.1.0.M1


Termination is more correct if you take a look at articles etc.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 18 08:25:29 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 18 Jul 2009 08:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2213) When the decider
 doesn't pick a move,
 the DefaultLocalSearchSolver shouldn't terminate by exception by try again,
 especially with relativeSelection on
Message-ID: <1398005368.1247919929317.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

When the decider doesn't pick a move, the DefaultLocalSearchSolver shouldn't terminate by exception by try again, especially with relativeSelection on
------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2213
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2213
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-solver
    Affects Versions: 5.0.1.FINAL
            Reporter: Geoffrey De Smet
            Assignee: Geoffrey De Smet
            Priority: Critical


a random bad relativeSelection could select only moves that are tabu
that no reason to stop, because the next relativeSelection could be great.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 18 08:25:29 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sat, 18 Jul 2009 08:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2213) When the
 decider doesn't pick a move,
 the DefaultLocalSearchSolver shouldn't terminate by exception by try again,
 especially with relativeSelection on
In-Reply-To: <1398005368.1247919929317.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <766060953.1247919929427.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476768#action_12476768 ] 

Geoffrey De Smet commented on JBRULES-2213:
-------------------------------------------

look for "TODO JBRULES-2213"

> When the decider doesn't pick a move, the DefaultLocalSearchSolver shouldn't terminate by exception by try again, especially with relativeSelection on
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2213
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2213
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Critical
>
> a random bad relativeSelection could select only moves that are tabu
> that no reason to stop, because the next relativeSelection could be great.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 06:36:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 20 Jul 2009 06:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1398126543.1248086189184.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476827#action_12476827 ] 

Howard Gao commented on JBMESSAGING-1664:
-----------------------------------------

I plan to fix this in the following way:

1. Instead of loading only non-paged messages, we load all the messages from the table. This need to change the SQL statement

LOAD_UNPAGED_REFS=SELECT MESSAGE_ID, DELIVERY_COUNT, SCHED_DELIVERY FROM JBM_MSG_REF WHERE STATE = 'C' AND CHANNEL_ID = ? AND PAGE_ORD IS NULL ORDER BY ORD

to 

LOAD_UNPAGED_REFS=SELECT MESSAGE_ID, DELIVERY_COUNT, SCHED_DELIVERY, PAGE_ORD FROM JBM_MSG_REF WHERE STATE = 'C' AND CHANNEL_ID = ? ORDER BY ORD

We add the PAGE_ORD to the selected columns as we later need this value in the code.

2. In JDBCPersistenceManager.loadFromStart() method, it checks the PAGE_ORD value while iterating through the resultset. The first batch of messages with 'null' PAGE_ORD values are real non-paged message refs, so it loads them into memory queue. When it encounters the first message ref whose PAGE_ORD is not null, it stops loading any further message refs into memory queue. When it encounters the message ref with null PAGE_ORD again, it adds them to a list and in the end update those messages with proper PAGE_ORD values.

So this way, when the JBM server is restarted, the message order will be maintained.





> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 06:40:40 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Mon, 20 Jul 2009 06:40:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6789) Allow applications
 to override logging by placing a log4j.xml inside it
In-Reply-To: <4502880.1239799773655.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2084333989.1248086440539.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476828#action_12476828 ] 

Pete Muir commented on JBAS-6789:
---------------------------------

Simply for a deployment to provide it's own logging configuration, using whatever logging configuration format/system is used by JBoss AS. (Definitely should be the same as JBoss AS, not different - I wrote log4j as that is what JBoss used until now :-)

> Allow applications to override logging by placing a log4j.xml inside it
> -----------------------------------------------------------------------
>
>                 Key: JBAS-6789
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6789
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: Pete Muir
>            Assignee: David Lloyd
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 06:40:40 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Mon, 20 Jul 2009 06:40:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1218094003.1248086440640.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476830#action_12476830 ] 

Tim Fox commented on JBMESSAGING-1664:
--------------------------------------

Err, isn't the whole point of paging, that it's not possible (not enough RAM) to load *all* the messages into memory at once?

> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 05:16:30 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Mon, 20 Jul 2009 05:16:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1674) add netty
	https support
In-Reply-To: <91041005.1246442551264.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1026060253.1248081390078.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor closed JBMESSAGING-1674.
------------------------------------

    Resolution: Done


> add netty https support
> -----------------------
>
>                 Key: JBMESSAGING-1674
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1674
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 2.0.0.beta3
>            Reporter: Andy Taylor
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>
> Netty has has support added for https when using the servlet transport. we need to make sure we support this fully and add an example. This will be available in netty 2.0.0.CR2 upwards

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 05:01:43 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jul 2009 05:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1014) NAKACK: SET_DIGEST
 does not overwrite the digest
Message-ID: <299603632.1248080503568.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

NAKACK: SET_DIGEST does not overwrite the digest
------------------------------------------------

                 Key: JGRP-1014
                 URL: https://jira.jboss.org/jira/browse/JGRP-1014
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.8


When we set a digest in NAKACK, we do not overwrite an element for a member if it already exists. With state transfer, the following issue can occur (see [1]):
Scenario #2:
- [NAKACK] D receives B:11 (digest is 11 now for B)
- [NAKACK] D applies the digest: this does NOT reset the digest for B to #10, but it remains #11 !!
- D delivers B:11 to the app, changes state
- D sets state, overwriting the change from B:11
--> B:11 will NOT get retransmitted as the digest in NAKACK contains it !
--> B:11 is lost

SOLUTION: maybe add a 'state' boolean to the setDigest() method and overwrite if true

This is a regression in 2.8 only; 2.6.x and 2.4.x handle SET_DIGEST correctly and do overwrite the digest.

[1] https://jira.jboss.org/jira/browse/JGRP-1013

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 04:54:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Jul 2009 04:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1013) STATE_TRANSFER /
 STREAMING_STATE_TRANSFER: close BARRIER before applying state response
Message-ID: <1427570229.1248080069185.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

STATE_TRANSFER / STREAMING_STATE_TRANSFER: close BARRIER before applying state response
---------------------------------------------------------------------------------------

                 Key: JGRP-1013
                 URL: https://jira.jboss.org/jira/browse/JGRP-1013
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.6.11, 2.8


Current, both state transfer protocols close the barrier, process the state *request* and re-open it. However, this is NOT done for state *responses* !

The following issue could happen:
- D requests the state from A
- B multicasts #11
- D receives the digest A:5, B:10, C:44 and (in parallel) B:11

Scenario #1:
- [NAKACK] D applies the digest (is 10 for B)
- [NAKACK] D receives B:11 (is 11 now for B)
- D delivers B:11 to the app, changes state
- D sets state, overwrites the change made by B:11
--> B:11 will *not* get retransmitted as the digest in NAKACK already has it: the change made by B:11 is lost !

Scenario #2:
- [NAKACK] D receives B:11 (is 11 now for B)
- [NAKACK] D applies the digest: resets the digest for B to #10
- D sets state
- D delivers B:11 to the app, changes state
--> B:11 will get retransmitted as the digest in NAKACK doesn't contain it
--> B:11 changes state *again*: B:11 is delivered *twice* !


So scenario #1 loses B:11 while scenario #2 delivers B:11 twice, which has to be prevented.

SOLUTION: 
- Close BARRIER before state response is handled (similar to what we do with a state request)
- This way, either B:11 is handled and changes the digest in NAKACK and the app state *before* we set the digest in NAKACK and the app state, OR the digest is set in NAKACK and the app state is set from the state response and THEN B:11 is handled




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 03:10:53 2009
From: jira-events at lists.jboss.org (Colin Mondesir (JIRA))
Date: Mon, 20 Jul 2009 03:10:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1689) Pass
 trustStore parameters to remoting layer
Message-ID: <369523920.1248073853274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Pass trustStore parameters to remoting layer
--------------------------------------------

                 Key: JBMESSAGING-1689
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1689
             Project: JBoss Messaging
          Issue Type: Feature Request
          Components: JMS Security
    Affects Versions: 1.4.0.SP3
            Reporter: Colin Mondesir
            Assignee: Howard Gao


The two trustStore parameters:

org.jboss.remoting.trustStorePassword
org.jboss.remoting.trustStore

Are not currently passed by JBM to the remoting layer.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 03:33:41 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Mon, 20 Jul 2009 03:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
In-Reply-To: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1849770554.1248075221811.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476803#action_12476803 ] 

Lukas Krejci commented on JBAS-7108:
------------------------------------

The integration test is succeeding because there are no methods invoked on the EJBs (see the TODOs in Ejb3MetricsUnitTestCase.validateInvocationStats() method). In Jopr case we actually invoke the methods on the EJBs. The stats collection fails only then.

> Unable to collect EJB3 invocation statistics
> --------------------------------------------
>
>                 Key: JBAS-7108
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>
> When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:
> java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 02:29:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 20 Jul 2009 02:29:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1671311537.1248071369348.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476801#action_12476801 ] 

Howard Gao commented on JBMESSAGING-1664:
-----------------------------------------

The paging can disrupt the order of message delivery in the following way:

1. Starting a queue with fullSize=20, pageSize=10, downCacheSize=10
2. Sending 35 persistent messages (m0 to m34) to the queue
3. The JBM_MSG_REF table will look like this:

[code]
+------------------+----------+
| MESSAGE_ID       | PAGE_ORD |
+------------------+----------+
|    m0's id       |     NULL | 
|     ....         |     NULL | 
|    m19's id      |     NULL | 
|    m20's id      |        0 | 
|     ....         |        5 | 
|    m29's id      |        9 | 
|    m30's id      |     NULL | 
|      ....        |     NULL | 
|    m34's id      |     NULL | 
+------------------+----------+
[/code]

No the order of messages in the table is exactly the same order as they were added to the in-memory queue, only
that m20 to m34 are paged and waiting to be loaded to the in-mem queue. Please note that messages m0 to m19 have 
NULL page_ord because they are in-memory messages, messages m20 to m29 have non-null page_ord values because they
have been paged down to DB, messages m30 to m34 have NULL page_ord values because they are in the down cache and haven't 
yet been written to DB.

If we at the moment shutdown and restart the server, the messages will be loaded from the DB in the same order as before.

But if we cosume a message (m19) before shutdown, it's possible that the table may look like this

[code]
+------------------+----------+
| MESSAGE_ID       | PAGE_ORD |
+------------------+----------+
|    m0's id       |     NULL | 
|     ....         |     NULL | 
|    m18's id      |     NULL | 
|    m20's id      |        0 | 
|     ....         |        5 | 
|    m29's id      |        9 | 
|    m30's id      |     NULL | 
|      ....        |     NULL | 
|    m34's id      |     NULL | 
+------------------+----------+
[/code]

Now if we start the server again, it will load m0 to m18, plus m30 into the in-memory queue and update the paging status. The key sql statement is this

[code]
LOAD_UNPAGED_REFS=SELECT MESSAGE_ID, DELIVERY_COUNT, SCHED_DELIVERY FROM JBM_MSG_REF WHERE STATE = 'C' AND CHANNEL_ID = ? AND PAGE_ORD IS NULL ORDER BY ORD
[/code]

This will cause m30 to be delivered before messages m20 to m29. So the order is broken.


http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244557#4244557

> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 15:40:29 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 20 Jul 2009 15:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-136) JBoss STS - add
 support for batch requests
Message-ID: <1124938795.1248118829193.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss STS - add support for batch requests 
-------------------------------------------

                 Key: JBID-136
                 URL: https://jira.jboss.org/jira/browse/JBID-136
             Project: JBoss Identity
          Issue Type: Task
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha3
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: IDFED-1.0.0.alpha4


The WS-Trust specification defines the concept of batch requests in which a client can ask for multiple tokens to be issued/validated/renewed/cancelled using a single WS-Trust request. The STS must be changed so it can process such requests.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 15:44:29 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 20 Jul 2009 15:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBID-136) JBoss STS - add
 support for batch requests
In-Reply-To: <1124938795.1248118829193.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1114725905.1248119069196.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBID-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476912#action_12476912 ] 

Stefan Guilhen commented on JBID-136:
-------------------------------------

The rules for batch processing are as follows:

- if any of the requests fails, the whole request processing must fail with an exception. So, either all requests are successfully handled or an exception must be thrown.
- all the requests  in the batch must be of the same "type" (BatchIssue, BatchValidate, etc). An exception will be thrown if the request types differ.

> JBoss STS - add support for batch requests 
> -------------------------------------------
>
>                 Key: JBID-136
>                 URL: https://jira.jboss.org/jira/browse/JBID-136
>             Project: JBoss Identity
>          Issue Type: Task
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.alpha4
>
>
> The WS-Trust specification defines the concept of batch requests in which a client can ask for multiple tokens to be issued/validated/renewed/cancelled using a single WS-Trust request. The STS must be changed so it can process such requests.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 13:14:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 17 Jul 2009 13:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
In-Reply-To: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <85611383.1247850869197.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476744#action_12476744 ] 

Andrew Lee Rubinger commented on JBAS-7108:
-------------------------------------------

I'll have a look and see what is causing the CCE, and more importantly, why the integration test does not reveal it.

> Unable to collect EJB3 invocation statistics
> --------------------------------------------
>
>                 Key: JBAS-7108
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>
> When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:
> java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 13:12:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 17 Jul 2009 13:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
In-Reply-To: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <486858156.1247850749274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger reassigned JBAS-7108:
-----------------------------------------

    Assignee: Andrew Lee Rubinger


> Unable to collect EJB3 invocation statistics
> --------------------------------------------
>
>                 Key: JBAS-7108
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>
> When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:
> java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 12:50:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 17 Jul 2009 12:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7107) Invocation
 statistics not collected on JMX based EJB2 managed components
In-Reply-To: <381985128.1247839649313.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1330040214.1247849429326.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476741#action_12476741 ] 

Jason T. Greene commented on JBAS-7107:
---------------------------------------

The test says they are working just fine:

http://hudson.qa.jboss.com/hudson/view/EAP-CI/job/JBoss-EAP-5.0.x-Testsuite-sun16/50/testReport/org.jboss.test.profileservice.test/JMXMappingUnitTestCase(profileservice)/testEjbMetrics/

Are you sure the test was hitting the right branch?

> Invocation statistics not collected on JMX based EJB2 managed components
> ------------------------------------------------------------------------
>
>                 Key: JBAS-7107
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7107
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>
> This was brought to light while investigating JOPR-280.
> During the Jopr AS5 plugin integration tests the metrics collection on EJB2 SFSBs, SLSBs, MDBs and Entity beans is tested.
> For session beans a single remote method is called 10 times on a single bean. The test then checks for CreateCount == 1 and for appropriate method invocation statistics.
> Both the create count and the invocation stats are always 0/empty. Note that this is also true for the MBeans of the session beans themselves when looking at the values in the jmx-console.
> For MDBs the collection statistics fails "most of the time". This might be because the JNDI name of a bean contains @object-id. Once some messages are delivered to the bean the @object-id part of the JNDI name changes from time to time. I suspect that with that change, the stats go as well.
> Entity bean metrics seem to be collected fine.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 12:47:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 17 Jul 2009 12:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
In-Reply-To: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1596890511.1247849249256.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476739#action_12476739 ] 

Andrew Lee Rubinger commented on JBAS-7108:
-------------------------------------------

The integration test in JBPAPP is coming up fine.  What's the test environment leading to this exception?  I suspect a mismatch somewhere.

> Unable to collect EJB3 invocation statistics
> --------------------------------------------
>
>                 Key: JBAS-7108
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Priority: Critical
>
> When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:
> java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 11:22:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Fri, 17 Jul 2009 11:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
Message-ID: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Unable to collect EJB3 invocation statistics
--------------------------------------------

                 Key: JBAS-7108
                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.2.0.Beta1
            Reporter: Lukas Krejci
            Priority: Critical


When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:

java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)
	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)

This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 12:00:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Fri, 17 Jul 2009 12:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
In-Reply-To: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <37453870.1247846429614.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476729#action_12476729 ] 

Lukas Krejci commented on JBAS-7108:
------------------------------------

This occurs because of org.jboss.ebj3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue() method in the jboss-ejb3-metrics-deployer project.

> Unable to collect EJB3 invocation statistics
> --------------------------------------------
>
>                 Key: JBAS-7108
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Priority: Critical
>
> When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:
> java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jul 19 05:36:29 2009
From: jira-events at lists.jboss.org (Nikolay Botev (JIRA))
Date: Sun, 19 Jul 2009 05:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (HIBERNATE-112) Schema auto
 generation creates columns in alphabetical order for compound primary keys
In-Reply-To: <33331140.1237737862579.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <951778208.1247996189306.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/HIBERNATE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476783#action_12476783 ] 

Nikolay Botev commented on HIBERNATE-112:
-----------------------------------------

The other bug is ANN-551, look it up here; http://opensource.atlassian.com/projects/hibernate/browse/ANN-551

> Schema auto generation creates columns in alphabetical order for compound primary keys
> --------------------------------------------------------------------------------------
>
>                 Key: HIBERNATE-112
>                 URL: https://jira.jboss.org/jira/browse/HIBERNATE-112
>             Project: Hibernate
>          Issue Type: Bug
>         Environment: JBoss AS 5.0.1 with EJB3 entities / Hibernate with MySQL Server 5.1
>            Reporter: Jochen Reinhardt
>            Assignee: Steve Ebersole
>
> Schema auto generation creates columns in alphabetical order.
> I would not mind that, but it also affects the creation of primary key indexes. These are rather useless from a database point of view, as the database will only be able to use an index for searching if the columns that are searched for are a prefix of the key. Alphabetical column order is not what one expects. Instead, I would want that my columns are sorted in the same way they appear in my annotated POJO class. I hope I am not missing some simple configuration issue...
> I have a rather complex setup with my entities and relations, using compound primary keys and references. In an entity that maps a complex m:n relationship between two entities with additional properties... Please let me know if you need more details.
> I'm using @Embedded on a primary key class and @EmbeddedId in all my entities.
> I already posted in the Hibernate forums, but I did not get an answer yet, nor did I find any information about my specific problem. The only peace of information I found so far is, that the alphabetical column sort order was introduced because of some issues related to foreign key constraints in clustered environments.  As it is already somewhat urgent, I decided to submit a bug report.
> A colleague of mine found the following in some other forum and I looked up in the source code, too - it's still there. But I do not know if it is correct in general and it only does not work for my setup.
> Cite:
> Hi all,
> I am using EJB3 with hibernate.hbm2ddl.auto=update. I notice the primary keys is been created in database in alphabetic order and not like the order defined at the embedded class. I look at the source code of Hibernate Annotations and found in AnnotationBinder class a Collections.sort at line 1024 with this comment:
> //order so that property are used in the same order when binding native query
> In my project I have primary keys with 4 or 5 fields, and many queries use only 2 ou 3 of them and are running very slow, and the cause was the wrong order of the primary keys in the database.
> I guest that sort is for fixing another bug, but is really annoying, because I need to look each primary key and adjust its order by hand.
> Is there another solution?
> Thanks in advance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jul 19 04:23:29 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 19 Jul 2009 04:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2212) Rename Finish
 interface to Termination.
In-Reply-To: <2113079936.1247918909237.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1720035088.1247991809205.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476782#action_12476782 ] 

Geoffrey De Smet commented on JBRULES-2212:
-------------------------------------------

see upgrade recipe

> Rename Finish interface to Termination.
> ---------------------------------------
>
>                 Key: JBRULES-2212
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2212
>             Project: JBoss Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>             Fix For: 5.1.0.M1
>
>
> Termination is more correct if you take a look at articles etc.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jul 19 04:19:29 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 19 Jul 2009 04:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-1373) Rename
 FeasibleScoreTermination to ScoreAttainedTermination
In-Reply-To: <19006052.1197046371584.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1083106601.1247991569150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated JBRULES-1373:
--------------------------------------

          Summary: Rename FeasibleScoreTermination to ScoreAttainedTermination  (was: Rename feasibleScoreFinish)
    Fix Version/s: 5.1.0.M1


> Rename FeasibleScoreTermination to ScoreAttainedTermination
> -----------------------------------------------------------
>
>                 Key: JBRULES-1373
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1373
>             Project: JBoss Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Optional
>             Fix For: 5.1.0.M1
>
>
> scoreReachedFinish might be more appropriate and less confusing with "feasible solutions"
> because a feasible solution would be able to have an unfeasible score?!?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jul 19 04:21:29 2009
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 19 Jul 2009 04:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1373) Rename
 FeasibleScoreTermination to ScoreAttainedTermination
In-Reply-To: <19006052.1197046371584.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1894430273.1247991689192.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet resolved JBRULES-1373.
---------------------------------------

    Resolution: Done


see upgrade recipe

> Rename FeasibleScoreTermination to ScoreAttainedTermination
> -----------------------------------------------------------
>
>                 Key: JBRULES-1373
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-1373
>             Project: JBoss Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: drools-solver
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Optional
>             Fix For: 5.1.0.M1
>
>
> scoreReachedFinish might be more appropriate and less confusing with "feasible solutions"
> because a feasible solution would be able to have an unfeasible score?!?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 10:07:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Fri, 17 Jul 2009 10:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7107) Invocation
 statistics not collected on JMX based EJB2 managed components
Message-ID: <381985128.1247839649313.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Invocation statistics not collected on JMX based EJB2 managed components
------------------------------------------------------------------------

                 Key: JBAS-7107
                 URL: https://jira.jboss.org/jira/browse/JBAS-7107
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.2.0.Beta1
            Reporter: Lukas Krejci


This was brought to light while investigating JOPR-280.

During the Jopr AS5 plugin integration tests the metrics collection on EJB2 SFSBs, SLSBs, MDBs and Entity beans is tested.

For session beans a single remote method is called 10 times on a single bean. The test then checks for CreateCount == 1 and for appropriate method invocation statistics.
Both the create count and the invocation stats are always 0/empty. Note that this is also true for the MBeans of the session beans themselves when looking at the values in the jmx-console.

For MDBs the collection statistics fails "most of the time". This might be because the JNDI name of a bean contains @object-id. Once some messages are delivered to the bean the @object-id part of the JNDI name changes from time to time. I suspect that with that change, the stats go as well.

Entity bean metrics seem to be collected fine.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 16:04:29 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 20 Jul 2009 16:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-137) JBoss STS - improve
 the configuration to allow for general properties to be specified for each
 token provider
Message-ID: <333146513.1248120269086.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss STS - improve the configuration to allow for general properties to be specified for each token provider
-------------------------------------------------------------------------------------------------------------

                 Key: JBID-137
                 URL: https://jira.jboss.org/jira/browse/JBID-137
             Project: JBoss Identity
          Issue Type: Task
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha3
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: IDFED-1.0.0.alpha4


JBoss STS does not currently provide a way to specify general properties for a token provider. A token provider may be configurable (for example, a provider may take an URL of a third-party service or repository) and the configuration schema must be changed to allow the specification of properties.

The token providers should also be associated with the token element (namespace and local name) besides the token type. The reason for doing this is that validation/renewing/cancellation requests do not specify the token type explicitly so it must be inferred by the token element. The only way for the STS to figure out which provider should be used to validate the token is by having an association between token elements and providers. Something like:

<TokenProvider ProviderClass="...." TokenType="..." TokenNamespace="urn:...." TokenName="Assertion">
    <Property name="..." value="..."/>
    <Property name="..." vluae="..."/>
</TokenProvider>

A final note about configuration is about the need for the TruststoreAlias attribute of the ServiceProvider. The alias of each service provider can be configured through the ValidatingAlias element of KeyProvider, so we may just make the TruststoreAlias attribute optional.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 16:10:29 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 20 Jul 2009 16:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-138) JBoss STS - implement
 proof-of-possession token logic
Message-ID: <65021309.1248120629197.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss STS - implement proof-of-possession token logic
-----------------------------------------------------

                 Key: JBID-138
                 URL: https://jira.jboss.org/jira/browse/JBID-138
             Project: JBoss Identity
          Issue Type: Task
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha3
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: IDFED-1.0.0.alpha4


The WS-Trust specification defines the concept of a proof-of-possession token, that is, a token that can be used to verify the association between a security token and a subject. We must add support for proof tokens, both symmetric (secret key) and assymetric (certificate based). The proof must no only be included in the WS-Trust response, but also in the security tokens being generated by each token provider.

Once this has been implemented, we must change the SAML20TokenProvider so it adds the appropriate proof token to the assertion being created.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 11:00:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 17 Jul 2009 11:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2211)
 StatefulKnowledgeSession leaves threads running
Message-ID: <363522950.1247842829232.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

StatefulKnowledgeSession leaves threads running
-----------------------------------------------

                 Key: JBRULES-2211
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2211
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL, 5.0.0.FINAL
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.1.0.M1



Hi all,

 I've downloaded Drools fusion sample and started to make some changes to
the code (first of all wipe out the UI so I can test it easier).
 I tried to get to a minimal set so I can run a console main class and see
what happens but I am facing a strange behaviour.
 As soon as I start pushing events into the WorkingMemoryEntryPoint
("StockTick stream") a Thread - not daemonized since it blocks shutdown from
ending - is spawned and this prevents my JVM from shutting down (obviously
if I call System.exit(0) it will but I am avoiding this).
 I've tried both to halt and dispose the session that this entry point
belongs but with no success. Does anyone know how could I get rid of this
thread?
==================

Hi Edson!

 as I've already mentioned I've modified the sample so, if you get the StockTick sample and replace the Main class this will run fine.
 The sample shuts down fine but as I saw it sets the JFrame uses frame.setDefaultCloseOperation( WindowConstants.EXIT_ON_CLOSE ); which in turn makes the trick.

 Below the code of my modified main class:

package org.drools.examples.broker;


import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseConfiguration;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.builder.ResourceType;
import org.drools.conf.EventProcessingOption;
import org.drools.examples.broker.model.Company;
import org.drools.examples.broker.model.CompanyRegistry;
import org.drools.examples.broker.model.StockTick;
import org.drools.io.ResourceFactory;
import org.drools.runtime.StatefulKnowledgeSession;
import org.drools.runtime.rule.WorkingMemoryEntryPoint;

public class Main {
    private static final String RULES_FILE = "/broker.drl";
    static StatefulKnowledgeSession session;
    static WorkingMemoryEntryPoint tickStream;

    /**
     * @param args
     */
    public static void main(String[] args) throws Exception {
        // set up and show main window
       
        CompanyRegistry companies = new CompanyRegistry();
       
        KnowledgeBuilder builder = KnowledgeBuilderFactory.newKnowledgeBuilder();
        try {
            builder.add( ResourceFactory.newInputStreamResource( Main.class.getResourceAsStream( RULES_FILE ) ),
                         ResourceType.DRL);
        } catch ( Exception e ) {
            e.printStackTrace();
        }
        if( builder.hasErrors() ) {
            System.err.println(builder.getErrors());
            System.exit( 0 );
        }

        KnowledgeBaseConfiguration conf = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
        conf.setOption( EventProcessingOption.STREAM );
        KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase( conf );
        kbase.addKnowledgePackages( builder.getKnowledgePackages() );
       
        session = kbase.newStatefulKnowledgeSession();

        session.setGlobal( "services", new BrokerServices() {
            public void log(String message) {
                System.out.println(message);               
            }
        });

        for( Company company : companies.getCompanies() ) {
            session.insert( company );
        }
        session.fireAllRules();
       
        tickStream = session.getWorkingMemoryEntryPoint( "StockTick stream" );
 
        for (int i=10;i>0;i--) {
            tickStream.insert(new StockTick("RHT", i*10, System.currentTimeMillis()));
            session.getAgenda().getAgendaGroup( "evaluation" ).setFocus();
            session.fireAllRules();
        }
        session.dispose();
        session.halt();
        System.out.println("Still running...");
    }
   
}


regards,
Rafael Ribeiro

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 16:17:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 20 Jul 2009 16:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-4974) Upgrade to log4j
 1.2.15 in JBoss5.0
In-Reply-To: <9052822.1195095618615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1855167105.1248121049542.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-4974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned JBAS-4974:
---------------------------------

    Assignee: David Lloyd  (was: Scott M Stark)


> Upgrade to log4j 1.2.15 in JBoss5.0
> -----------------------------------
>
>                 Key: JBAS-4974
>                 URL: https://jira.jboss.org/jira/browse/JBAS-4974
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.0.0.Beta2
>            Reporter: cheng dan
>            Assignee: David Lloyd
>            Priority: Minor
>
> Please upgrade to the latest stable log4j release 1.2.15 in JBoss5.0
> http://logging.apache.org/log4j/1.2/download.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 16:19:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 20 Jul 2009 16:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-4974) Upgrade to log4j
 1.2.15 in JBoss5.0
In-Reply-To: <9052822.1195095618615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <74077697.1248121169237.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-4974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBAS-4974.
-----------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


We have updated to 1.2.15 in 6.0.  However the logging configuration uses an alternate mechanism now, so I'm not sure this will fix your problem...

> Upgrade to log4j 1.2.15 in JBoss5.0
> -----------------------------------
>
>                 Key: JBAS-4974
>                 URL: https://jira.jboss.org/jira/browse/JBAS-4974
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.0.0.Beta2
>            Reporter: cheng dan
>            Assignee: David Lloyd
>            Priority: Minor
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Please upgrade to the latest stable log4j release 1.2.15 in JBoss5.0
> http://logging.apache.org/log4j/1.2/download.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 08:42:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 17 Jul 2009 08:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1670) Disallow
 forward slashes in jms destinations
In-Reply-To: <15439568.1246092776416.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1050270959.1247834549336.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1670.
------------------------------------

    Resolution: Rejected


the destination name is never used to bind to JNDI.

In JBM 2.x, the JNDI bindings are mandatory and we will never default to the destination name to bind to JNDI.
Having forward slashes in the destination name is not an issue (see JMSServerDeployerTest)

> Disallow forward slashes in jms destinations
> --------------------------------------------
>
>                 Key: JBMESSAGING-1670
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1670
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> We need to disallow forward slashes in JMS destination names since they won't be able to be deployed in JNDI since the slash will be interperted as a subcontext by JNDI

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 16:22:29 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 20 Jul 2009 16:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-139) JBoss STS - implement
 token encryption logic
Message-ID: <1615009684.1248121349351.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss STS - implement token encryption logic
--------------------------------------------

                 Key: JBID-139
                 URL: https://jira.jboss.org/jira/browse/JBID-139
             Project: JBoss Identity
          Issue Type: Task
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha3
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: IDFED-1.0.0.alpha4


When the EncryptToken property is set to true, the STS must encrypt the issued token using the service provider PKC. If either the service provider or its PKC is not available (a request can be made without specifying the target service provider) we should log a warn message and leave the token unencrypted.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 06:54:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Fri, 17 Jul 2009 06:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7106) Deployment Based
 On An EAR's application.xml Order No Longer Works
In-Reply-To: <1569390802.1247806049341.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1029113898.1247828069256.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476674#action_12476674 ] 

Ales Justin commented on JBAS-7106:
-----------------------------------

Previous discussion found by Alexey:
* http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4121271
* http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4127369#4127369

> Deployment Based On An EAR's application.xml Order No Longer Works
> ------------------------------------------------------------------
>
>                 Key: JBAS-7106
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7106
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>            Reporter: Jimmy Wilson
>            Assignee: Ales Justin
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-5.0.2.GA
>
>
> During deployment, even though <module-order>strict</module-order> is specified in jboss-app.xml, the EAR deployer still deploys in alphabetical order.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 05:41:29 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 17 Jul 2009 05:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1688) transaction
 support in the JCA adapter isn't implemented properly
Message-ID: <92600155.1247823689314.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

transaction support in the JCA adapter isn't implemented properly
-----------------------------------------------------------------

                 Key: JBMESSAGING-1688
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1688
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0.beta3
            Reporter: Andy Taylor
            Assignee: Tim Fox
             Fix For: 2.0.0




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 05:45:29 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 17 Jul 2009 05:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBMESSAGING-1688) transaction
 support in the JCA adapter isn't implemented properly
Message-ID: <370770056.1247823929209.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor deleted JBMESSAGING-1688:
-------------------------------------


> transaction support in the JCA adapter isn't implemented properly
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-1688
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1688
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Andy Taylor
>            Assignee: Andy Taylor
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 05:36:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Fri, 17 Jul 2009 05:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1687) Transaction
 management/demarcation and ack modes/session creation broken in JCA RA
Message-ID: <615256574.1247823389304.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Transaction management/demarcation and ack modes/session creation broken in JCA RA
----------------------------------------------------------------------------------

                 Key: JBMESSAGING-1687
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1687
             Project: JBoss Messaging
          Issue Type: Bug
            Reporter: Tim Fox
            Assignee: Tim Fox
            Priority: Critical
             Fix For: 2.0.0




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 05:43:29 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 17 Jul 2009 05:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1688) transaction
 support in the JCA adapter isn't implemented properly
In-Reply-To: <92600155.1247823689314.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1489954114.1247823809195.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor closed JBMESSAGING-1688.
------------------------------------

    Resolution: Duplicate Issue


> transaction support in the JCA adapter isn't implemented properly
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-1688
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1688
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>            Reporter: Andy Taylor
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 05:45:29 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 17 Jul 2009 05:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1687) Transaction
 management/demarcation and ack modes/session creation broken in JCA RA
In-Reply-To: <615256574.1247823389304.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <958668194.1247823929393.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor reassigned JBMESSAGING-1687:
----------------------------------------

    Assignee: Andy Taylor  (was: Tim Fox)


> Transaction management/demarcation and ack modes/session creation broken in JCA RA
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1687
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1687
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Andy Taylor
>            Priority: Critical
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 05:41:29 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Fri, 17 Jul 2009 05:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1688) transaction
 support in the JCA adapter isn't implemented properly
In-Reply-To: <92600155.1247823689314.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1918811371.1247823689506.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor reassigned JBMESSAGING-1688:
----------------------------------------

    Assignee: Andy Taylor  (was: Tim Fox)


> transaction support in the JCA adapter isn't implemented properly
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-1688
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1688
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>            Reporter: Andy Taylor
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 04:46:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 17 Jul 2009 04:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1012) TP: fetch physical
 address associated with logical address more quickly
Message-ID: <547183200.1247820389194.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

TP: fetch physical address associated with logical address more quickly
-----------------------------------------------------------------------

                 Key: JGRP-1012
                 URL: https://jira.jboss.org/jira/browse/JGRP-1012
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.8


Currently, when we send a unicast message and don't have the physical address available, we send a discovery request for the physical address and trash the message.

Later, when the physical address has been received and added to the transport's cache, the retransmission of the unicast message will succeed.

In order not to generate too much traffic, we send such a discovery request only every 5 seconds (hard-coded) max. However, this is for *all* addresses. So if we have physical addresses for P, Q and R missing, the total time to send the 3 discovery requests will be 15 sec max ! So we would not be able to send a unicast to R for up to 15 secs !

This is bad, we should keep track of *which* addresses we've sent out discovery requests for, and have timeouts based on individual addresses, for example in the form of a cache (keys=addrs, values=last time sent).


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 03:47:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 17 Jul 2009 03:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1009) Prevent merging
 during JOIN/LEAVE processing
In-Reply-To: <1137846767.1246631211429.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1738943336.1247816849131.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476659#action_12476659 ] 

Bela Ban commented on JGRP-1009:
--------------------------------

Workaround: start all instances in a cluster in staggered fashion

> Prevent merging during JOIN/LEAVE processing
> --------------------------------------------
>
>                 Key: JGRP-1009
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1009
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.9
>
>
> - Say we have V1={A,B,C} and D joins
> - A multicasts the new view V2={A,B,C,D} to {A,B,C} and sends a it via unicast to D
> - At time T1, A and C have V2, but B might still have V1
> - At timeT3 B will also have V2
> - HOWEVER, *before* T3 (at T2), A's MERGE functionality gets the current views and discovers the discrepancy
> - A will now initiate a merge. This is superfluous because B would have received V2 at T3 (maybe a few ms later) !
> This is not incorrect, but we still want to prevent spurious merges.
> SOLUTION:
> - Turn off merging during view change processing
> - This can be done via discarding of MERGE events at GMS during view processing, or by disabling merging directly in MERGE2, MERGE3, MERGEFAST. The first option looks more promising, as it requires only 1 hange in GMS

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 03:43:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 17 Jul 2009 03:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-974) Make 2.9 run with
	JBoss 6.x
In-Reply-To: <21960561.1241605966588.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <576794340.1247816609253.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-974:
--------------------------

    Summary: Make 2.9 run with JBoss 6.x  (was: Make 2.9 run with JBoss 5.x)


Changed to make 2.9 run with AS 6. There won't be any support for 2.9 in AS 5 !

> Make 2.9 run with JBoss 6.x
> ---------------------------
>
>                 Key: JGRP-974
>                 URL: https://jira.jboss.org/jira/browse/JGRP-974
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.9
>
>
> Currently, 2.8 does not run with JBoss 5.x because 2.8 removed some JMX classes (see below).
> java.lang.NoSuchMethodError: org.jgroups.jmx.JmxConfigurator.registerChannel(Lorg/jgroups/JChannel;Ljavax/management/MBeanServer;Ljava/lang/String;Ljava/lang/String;Z)Lorg/jgroups/jmx/JChannel;
> 	at org.jboss.ha.framework.server.JChannelFactory.registerChannel(JChannelFactory.java:1019)
> 	at org.jboss.ha.framework.server.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:279)
> 	at org.jboss.ha.framework.server.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:309)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
> 	at javax.management.StandardMBean.invoke(StandardMBean.java:391)
> 	at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.messaging.core.impl.jchannelfactory.MultiplexerChannelFactory.createControlChannel(MultiplexerChannelFactory.java:130)
> 	at org.jboss.messaging.core.impl.postoffice.GroupMember.start(GroupMember.java:116)
> 	at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.start(MessagingPostOffice.java:367)
> 	at org.jboss.messaging.core.jmx.MessagingPostOfficeService.startService(MessagingPostOfficeService.java:462)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
> 	at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:269)
> and 
> 2009-05-06 12:23:15,553 ERROR [org.jboss.mx.server.registry.BasicMBeanRegistry] (main) Cannot register MBean
> java.lang.NoClassDefFoundError: org/jgroups/jmx/JChannelFactoryMBean
> 	at java.lang.Class.getDeclaredMethods0(Native Method)
> 	at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
> 	at java.lang.Class.privateGetPublicMethods(Class.java:2547)
> 	at java.lang.Class.privateGetPublicMethods(Class.java:2557)
> 	at java.lang.Class.getMethods(Class.java:1410)
> 	at org.jboss.mx.metadata.StandardMetaData.build(StandardMetaData.java:208)
> 	at org.jboss.mx.modelmbean.XMBean.<init>(XMBean.java:224)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:202)
> 	at sun.reflect.GeneratedMethodAccessor98.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.ha.cachemanager.CacheManager.registerCache(CacheManager.java:266)
> 	at org.jboss.cache.CacheManagerImpl.getCache(CacheManagerImpl.java:124)
> 	at org.jboss.ha.cachemanager.CacheManager.getCache(CacheManager.java:244)
> 	at org.jboss.ha.framework.server.HAPartitionCacheHandlerImpl.acquireCache(HAPartitionCacheHandlerImpl.java:53)
> 	at org.jboss.ha.framework.server.ClusterPartition.startService(ClusterPartition.java:355)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
> 	at org.jboss.system.ServiceMBeanSupport.pojoStart(ServiceMBeanSupport.java:216)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 01:10:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 17 Jul 2009 01:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7072) Don't write a URL for
 host 0.0.0.0 in jnp-service.url
In-Reply-To: <15437469.1246547091499.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <352734757.1247807429197.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7072.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> Don't write a URL for host 0.0.0.0 in jnp-service.url
> -----------------------------------------------------
>
>                 Key: JBAS-7072
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7072
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services, Naming
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> See JOPR-254 for an explanation of the issue. This issue is to ensure NamingServiceURLWriter writes the correct URL.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 17 00:47:29 2009
From: jira-events at lists.jboss.org (Jimmy Wilson (JIRA))
Date: Fri, 17 Jul 2009 00:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7106) Deployment Based On
 An EAR's application.xml Order No Longer Works
Message-ID: <1569390802.1247806049341.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Deployment Based On An EAR's application.xml Order No Longer Works
------------------------------------------------------------------

                 Key: JBAS-7106
                 URL: https://jira.jboss.org/jira/browse/JBAS-7106
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Deployers
    Affects Versions: JBossAS-5.1.0.GA, JBossAS-5.0.1.GA
            Reporter: Jimmy Wilson
            Assignee: Ales Justin
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-5.0.2.GA


During deployment, even though <module-order>strict</module-order> is specified in jboss-app.xml, the EAR deployer still deploys in alphabetical order.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 21:14:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 16 Jul 2009 21:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-115) Negative test for
 standard 303 validation annotation
In-Reply-To: <1562454476.1247472809212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1859957502.1247793269143.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang updated JBJCA-115:
-----------------------------

    Fix Version/s: 1.0.0.Alpha2
                       (was: 1.0.0.Alpha3)


> Negative test for standard 303 validation annotation
> ----------------------------------------------------
>
>                 Key: JBJCA-115
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-115
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> ra16standard303jbossra.rar (Invalid - must fail)
> define in ra.xml and override in jboss-ra.xml, validate should be fail

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 21:12:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 16 Jul 2009 21:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-119) Hibernate Validator
	4.0.0Beta1
In-Reply-To: <1098713284.1247792429189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <760415653.1247793149498.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang updated JBJCA-119:
-----------------------------

    Summary: Hibernate Validator 4.0.0Beta1  (was: Hibernate Validator 4.0.0)


> Hibernate Validator 4.0.0Beta1
> ------------------------------
>
>                 Key: JBJCA-119
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-119
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> for 303 requirement 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 20:46:29 2009
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 16 Jul 2009 20:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2210) Move
 getSessionClock from WorkingMemory to Runtime.
Message-ID: <1308806284.1247791589350.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Move getSessionClock from WorkingMemory to Runtime.
---------------------------------------------------

                 Key: JBRULES-2210
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2210
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-api
            Reporter: Mark Proctor
            Assignee: Mark Proctor




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 20:42:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 20:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <720064499.1247791349125.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476642#action_12476642 ] 

Richard Achmatowicz commented on JGRP-1011:
-------------------------------------------

Test results: I list the test which failed repeatedly, followed by the tests which failed, but passed on retry, organized by IP version.

ipv4:
repeatable failure:
* CloseTest(tcp).testMultipleConnectsAndDisconnects (also fails on 2.6.10.GA - no regression)
* FlushCloseOpenTest(tcp).testAndLoop (also fails on 2.6.10.GA - no regression)
passed on retry:
* none

ipv4.local:
repeatable failure:
* CloseTest(tcp).testMultipleConnectsAndDisconnects (also fails on 2.6.10.GA - no regression)
* FlushCloseOpenTest(tcp).testAndLoop (also fails on 2.6.10.GA - no regression)
passed on retry:
* SharedTransportTest(udp).testSendingOfMessageAfterChannelClose
* ConnectStressTest (timeout)

ipv6:
repeatable failure:
* CloseTest(tcp).testMultipleConnectsAndDisconnects (not testsed on 2.6.10.GA)
* FlushCloseOpenTest(tcp).testAndLoop (not tested on 2.6.10.GA)
passed on retry:
* MergeTest(udp).testMerging4Members

ipv6.local:
repeatable failure:
* CloseTest(tcp).testMultipleConnectsAndDisconnects (not testsed on 2.6.10.GA)
* FlushCloseOpenTest(tcp).testAndLoop (not tested on 2.6.10.GA)
* MergeTest(udp).testMerging4Members/testMerge4Members (this test is really broken for IPv6 as it uses IPv4 default mcast addresses and needs to be recrafted) 
passed on retry:
* ConnectStressTest (timeout)






> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 20:44:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 20:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <405592524.1247791469180.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated JGRP-1011:
--------------------------------------

    Attachment: JGroups_2_6_11_GA_reports.zip


The full set of automated test results.


> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>         Attachments: JGroups_2_6_11_GA_reports.zip
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 21:00:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 16 Jul 2009 21:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-119) Hibernate Validator
	4.0.0
Message-ID: <1098713284.1247792429189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Hibernate Validator 4.0.0
-------------------------

                 Key: JBJCA-119
                 URL: https://jira.jboss.org/jira/browse/JBJCA-119
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha2


for 303 requirement 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 19:07:29 2009
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Thu, 16 Jul 2009 19:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7079) Can't redirect root
 requests without ROOT.war
In-Reply-To: <1964202660.1246909311435.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1097048145.1247785649167.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Remy Maucherat resolved JBAS-7079.
----------------------------------

    Resolution: Won't Fix


Yes, the request must be mappable to a webapp for any processing to occur. This behavior has existed in Tomcat for a long time now, and is a feature request (that is not really doable, though).

> Can't redirect root requests without ROOT.war
> ---------------------------------------------
>
>                 Key: JBAS-7079
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7079
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows XP, JDK 1.6.0_14
>            Reporter: Rostyslav Smirnov
>            Assignee: Remy Maucherat
>
> When ROOT.war is removed, root URL request always returns 404, ignoring URL rewrite rules.
> Steps to reproduce:
> 1) Set up a single URL rewriting rule for jboss.web engine that redirects root requests:
> RewriteRule ^/$ /admin-console/ [R]
> At this point everything works and http://localhost:8080/ becomes http://localhost:8080/admin-console/
> 2) As the ROOT.war is now inaccessible, remove or rename it. Now http://localhost:8080/ just returns 404, ignoring the rule.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 17:39:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 16 Jul 2009 17:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBID-135) Release
 JBossIdentity 1.0.0.alpha4 consolidated stack
In-Reply-To: <1636549018.1247764829150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1093282804.1247780369842.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBID-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476632#action_12476632 ] 

Anil Saldhana commented on JBID-135:
------------------------------------

OpenID Integration: http://www.jboss.org/community/wiki/OpenIDIntegrationinJBossIdentity

> Release JBossIdentity 1.0.0.alpha4 consolidated stack
> -----------------------------------------------------
>
>                 Key: JBID-135
>                 URL: https://jira.jboss.org/jira/browse/JBID-135
>             Project: JBoss Identity
>          Issue Type: Release
>          Components: Community-Build
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDENTITY-1.0.0.alpha4
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 16:58:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 16 Jul 2009 16:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-535) Move task
 configuration in server-config.xml into a target
Message-ID: <1701874410.1247777909261.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Move task configuration in server-config.xml into a target
----------------------------------------------------------

                 Key: JBBUILD-535
                 URL: https://jira.jboss.org/jira/browse/JBBUILD-535
             Project: JBoss Build System
          Issue Type: Sub-task
            Reporter: Paul Gier




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 16:58:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 16 Jul 2009 16:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-535) Move task
 configuration in server-config.xml into a target
In-Reply-To: <1701874410.1247777909261.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <312303994.1247777909316.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-535:
------------------------------

    Description: Currently the task definitions in server-config.xml are not inside a target.  This means that they can't depend on another target to define their path references.  This should be changed so that everything is done inside targets.


> Move task configuration in server-config.xml into a target
> ----------------------------------------------------------
>
>                 Key: JBBUILD-535
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-535
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>
> Currently the task definitions in server-config.xml are not inside a target.  This means that they can't depend on another target to define their path references.  This should be changed so that everything is done inside targets.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 14:43:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Thu, 16 Jul 2009 14:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7050)
 "ClassNotFoundException:
 org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote
 calls to ManagementView.getTemplate()
Message-ID: <925585302.1247769809297.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukas Krejci resolved JBAS-7050.
--------------------------------

    Resolution: Done


It is possible to create both the data sources and connection factories remotely from JON now.

> "ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo" on remote calls to ManagementView.getTemplate()
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7050
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7050
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Lukas Krejci
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to create a datasource in AS5 using JON, the following exception occurs:
> java.lang.ClassNotFoundException: org.jboss.resource.deployers.management.DsDataSourceTemplateInfo                                                                                               
>         at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:103)                                                                                            
>         at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:86)                                                                                                 
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)                                                                                                                         
>         at java.lang.Class.forName0(Native Method)                                                                                                                                               
>         at java.lang.Class.forName(Class.java:247)                                                                                                                                               
>         at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:179)                                                                   
>         at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)                                                                                                               
>         at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)                                                                                                                  
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:119)                                                                                                  
>         at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792)                                                                                                               
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)                                                                                                              
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)                                                                                                                 
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)                                                                                                             
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)                                                                                                                    
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)                                                                                                                      
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:238)                                                        
>         at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:138)                                                                  
>         at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:123)                                                                              
>         at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59)                                                                                     
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1220)                                                                        
>         at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:850)                                                                             
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)                                                                                                 
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                                    
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                                     
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                            
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                          
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                        
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                        
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)                                                                                                                
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)                                                             
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.aop.generatedproxies.AOPProxy$1.getTemplate(AOPProxy$1.java)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createConfigurationBasedResource(ApplicationServerComponent.java:415)
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> I was only able to find this class in jboss-embedded-all maven module.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 13:34:40 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 16 Jul 2009 13:34:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-118) SJC/RADeployer:
 Merge specification and vendor metadata
Message-ID: <369789920.1247765680901.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC/RADeployer: Merge specification and vendor metadata
-------------------------------------------------------

                 Key: JBJCA-118
                 URL: https://jira.jboss.org/jira/browse/JBJCA-118
             Project: JBoss JCA
          Issue Type: Task
          Components: Deployer
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Merge the metadata from the specification (ConnectorMetaData) with our metadata (JBossRAMetaData).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 13:20:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 16 Jul 2009 13:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-135) Release JBossIdentity
 1.0.0.alpha4 consolidated stack
Message-ID: <1636549018.1247764829150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Release JBossIdentity 1.0.0.alpha4 consolidated stack
-----------------------------------------------------

                 Key: JBID-135
                 URL: https://jira.jboss.org/jira/browse/JBID-135
             Project: JBoss Identity
          Issue Type: Release
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 13:30:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 16 Jul 2009 13:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-135) Release JBossIdentity
 1.0.0.alpha4 consolidated stack
In-Reply-To: <1636549018.1247764829150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <33191448.1247765429372.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-135.
------------------------------

    Resolution: Done


> Release JBossIdentity 1.0.0.alpha4 consolidated stack
> -----------------------------------------------------
>
>                 Key: JBID-135
>                 URL: https://jira.jboss.org/jira/browse/JBID-135
>             Project: JBoss Identity
>          Issue Type: Release
>          Components: Community-Build
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDENTITY-1.0.0.alpha4
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 13:32:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 16 Jul 2009 13:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-101) SJC/RADeployer:
	Annotations
In-Reply-To: <387057390.1246458111738.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1930491883.1247765549507.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-101.
-----------------------------------

    Resolution: Done


> SJC/RADeployer: Annotations
> ---------------------------
>
>                 Key: JBJCA-101
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-101
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Handle annotations in the resource adapter to build a complete metadata model for the adapter.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 13:22:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 16 Jul 2009 13:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-135) Release JBossIdentity
 1.0.0.alpha4 consolidated stack
In-Reply-To: <1636549018.1247764829150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1263951989.1247764949320.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-135:
-------------------------------

    Component/s: Community-Build


> Release JBossIdentity 1.0.0.alpha4 consolidated stack
> -----------------------------------------------------
>
>                 Key: JBID-135
>                 URL: https://jira.jboss.org/jira/browse/JBID-135
>             Project: JBoss Identity
>          Issue Type: Release
>          Components: Community-Build
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDENTITY-1.0.0.alpha4
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 13:22:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 16 Jul 2009 13:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-135) Release JBossIdentity
 1.0.0.alpha4 consolidated stack
In-Reply-To: <1636549018.1247764829150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <707962810.1247764949216.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-135:
-------------------------------

    Fix Version/s: IDENTITY-1.0.0.alpha4


> Release JBossIdentity 1.0.0.alpha4 consolidated stack
> -----------------------------------------------------
>
>                 Key: JBID-135
>                 URL: https://jira.jboss.org/jira/browse/JBID-135
>             Project: JBoss Identity
>          Issue Type: Release
>          Components: Community-Build
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDENTITY-1.0.0.alpha4
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 13:32:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 16 Jul 2009 13:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-102) SJC/RADeployer:
 Merge annotations and metadata
In-Reply-To: <2016998490.1246458231392.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1576339021.1247765549633.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-102:
----------------------------------

    Summary: SJC/RADeployer: Merge annotations and metadata  (was: SJC/RADeployer: Merge metadata)


> SJC/RADeployer: Merge annotations and metadata
> ----------------------------------------------
>
>                 Key: JBJCA-102
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-102
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Merge the metadata from the XML and the annotations into a single model.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 13:20:29 2009
From: jira-events at lists.jboss.org (Tihomir Surdilovic (JIRA))
Date: Thu, 16 Jul 2009 13:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2060) change package
 format in drools-ant-tests from .dpkg to .pkg
In-Reply-To: <6008222.1239823702637.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <828410585.1247764829333.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tihomir Surdilovic updated JBRULES-2060:
----------------------------------------

    Fix Version/s: 5.1.0.M1
                       (was: 5.0.2)


> change package format in drools-ant-tests from .dpkg to .pkg
> ------------------------------------------------------------
>
>                 Key: JBRULES-2060
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2060
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-ant
>            Reporter: Tihomir Surdilovic
>            Assignee: Tihomir Surdilovic
>             Fix For: 5.1.0.M1
>
>
> drools-ant-tests example build file for binformat="package" creates .dpkg extension. This should follow the "standard" .pkg extension. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 13:32:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Thu, 16 Jul 2009 13:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7074) some jars required
 by remote Profile Service clients are not included in client/ or
 client/jbossall-client.jar's Manifest classpath
In-Reply-To: <631441563.1246562451433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2072459338.1247765549417.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7074:
-------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=154819


> some jars required by remote Profile Service clients are not included in client/ or client/jbossall-client.jar's Manifest classpath
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7074
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7074
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The following jar is missing from client/jbossall-client.jar's Manifest classpath and from client/:
>    common/lib/jboss-security-aspects.jar
> Its corresponding Maven artifact is org.jboss.aspects:jboss-security-aspects.
> If I find any others, I will update this JIRA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 12:06:41 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 16 Jul 2009 12:06:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-134) Release JBoss
 Identity Federation Stack 1.0.0.alpha4
Message-ID: <732256241.1247760401619.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Release JBoss Identity Federation Stack 1.0.0.alpha4
----------------------------------------------------

                 Key: JBID-134
                 URL: https://jira.jboss.org/jira/browse/JBID-134
             Project: JBoss Identity
          Issue Type: Release
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana


With the OpenID integration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 12:38:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 16 Jul 2009 12:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-134) Release JBoss Identity
 Federation Stack 1.0.0.alpha4
In-Reply-To: <732256241.1247760401619.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1668205321.1247762309341.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-134.
------------------------------

    Resolution: Done


> Release JBoss Identity Federation Stack 1.0.0.alpha4
> ----------------------------------------------------
>
>                 Key: JBID-134
>                 URL: https://jira.jboss.org/jira/browse/JBID-134
>             Project: JBoss Identity
>          Issue Type: Release
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> With the OpenID integration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 12:10:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 16 Jul 2009 12:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-134) Release JBoss
 Identity Federation Stack 1.0.0.alpha4
In-Reply-To: <732256241.1247760401619.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <825978082.1247760629135.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-134:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha4


> Release JBoss Identity Federation Stack 1.0.0.alpha4
> ----------------------------------------------------
>
>                 Key: JBID-134
>                 URL: https://jira.jboss.org/jira/browse/JBID-134
>             Project: JBoss Identity
>          Issue Type: Release
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> With the OpenID integration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 12:22:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 12:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <379195124.1247761349138.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476583#action_12476583 ] 

Richard Achmatowicz commented on JGRP-1011:
-------------------------------------------

The issue JGRP-956 has now been cleared up and was the result of an incorrect setting for java.net.preferIPv4Stack. See the JIRA issue for more details.

The updates to the issue also confirm that:
(i) binding to multicast sockets is possible in IPv6
(ii) when we do bind to miulticast, the crosstalk problem does not appear as in IPv4



> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 12:51:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 12:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-956) Binding to mcast
 address in UDP.java is not working on Linux with IPv6
In-Reply-To: <3739279.1239718822407.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <544345652.1247763089249.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz closed JGRP-956.
------------------------------------

    Fix Version/s: 2.4.7
                   2.6.11
       Resolution: Done


Changed error message in 2.6.11 - need to change for Branch 2.4 and Branch 2.8


> Binding to mcast address in UDP.java is not working on Linux with IPv6
> ----------------------------------------------------------------------
>
>                 Key: JGRP-956
>                 URL: https://jira.jboss.org/jira/browse/JGRP-956
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.4.7, 2.6.11, 2.8
>
>
> On Linux and Solaris platforms, when setting up the main multicast receiver socket, Bela allows binding the socket to its multicast address, like this:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> SocketAddress group_sock_addr = new InetSocketAddress(group_addr, port) ;
> MulticastSocket s = new MulticastSocket(group_sock_addr) ;    // funny
> s.joinGroup(group_addr) ;
> Binding to the multicast address on Linux and Solaris was done in order to avoid the promiscuous traffic problem. A detailed discussion on the matter can be found in the bugzilla report:https://bugzilla.redhat.com/show_bug.cgi?id=231899. 
> This works on Linux with IPv4 but is not working on Linux with IPv6 for the multicast-address ff02::1 - an error message is being generated (SocketException, invalid argument) and  the code then tries to create the same multicast address in the usual way:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> MulticastSocket s = new MulticastSocket(port) ;
> s.setInterface(bind_addr) ;
> s.joinGroup(group_addr) ;
> This is only a problem in that it generates a confusing error message about using mixed IPv4 / IPv6 stacks, but the socket continues to work correctly as far as I can tell.
> Haven't confirmed this, but I believe the promiscuous traffic issue does not arise with IPv6 multicast sockets.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 13:05:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 13:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <244359301.1247763929407.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476596#action_12476596 ] 

Richard Achmatowicz commented on JGRP-1011:
-------------------------------------------

There is still a problem when using scoped link-local IPv6 addresses, related to JDK issues. E.g. for addresses such as 

fe80::215:58ff:fec8:81a8%eth0

we get failures (messages are not delivered correctly), and this varies by JDK. So for this release, i'm not going to address these issues. 

Some of the problems were described in: https://jira.jboss.org/jira/browse/JGRP-976


> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 12:49:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 12:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-956) Binding to mcast
 address in UDP.java is not working on Linux with IPv6
In-Reply-To: <3739279.1239718822407.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <450807553.1247762969368.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476592#action_12476592 ] 

Richard Achmatowicz commented on JGRP-956:
------------------------------------------

On Brian's suggestion, changed to:

16:35:20,231 WARN [UDP] could not bind to /ff02:0:0:0:0:1:2:3 (IPv6 address); make sure your mcast_addr is of the same type as the preferred IP stack (IPv4 or IPv6), by checking the value of the system properties java.net.preferIPv4Stack and java.net.preferIPv6Addresses. Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details). Exception was: java.net.SocketException: Invalid argument


> Binding to mcast address in UDP.java is not working on Linux with IPv6
> ----------------------------------------------------------------------
>
>                 Key: JGRP-956
>                 URL: https://jira.jboss.org/jira/browse/JGRP-956
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> On Linux and Solaris platforms, when setting up the main multicast receiver socket, Bela allows binding the socket to its multicast address, like this:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> SocketAddress group_sock_addr = new InetSocketAddress(group_addr, port) ;
> MulticastSocket s = new MulticastSocket(group_sock_addr) ;    // funny
> s.joinGroup(group_addr) ;
> Binding to the multicast address on Linux and Solaris was done in order to avoid the promiscuous traffic problem. A detailed discussion on the matter can be found in the bugzilla report:https://bugzilla.redhat.com/show_bug.cgi?id=231899. 
> This works on Linux with IPv4 but is not working on Linux with IPv6 for the multicast-address ff02::1 - an error message is being generated (SocketException, invalid argument) and  the code then tries to create the same multicast address in the usual way:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> MulticastSocket s = new MulticastSocket(port) ;
> s.setInterface(bind_addr) ;
> s.joinGroup(group_addr) ;
> This is only a problem in that it generates a confusing error message about using mixed IPv4 / IPv6 stacks, but the socket continues to work correctly as far as I can tell.
> Haven't confirmed this, but I believe the promiscuous traffic issue does not arise with IPv6 multicast sockets.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 12:16:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 12:16:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-956) Binding to mcast
 address in UDP.java is not working on Linux with IPv6
In-Reply-To: <3739279.1239718822407.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1969186399.1247760989562.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476582#action_12476582 ] 

Richard Achmatowicz commented on JGRP-956:
------------------------------------------

May want to change the error message to:

16:35:20,231 WARN [UDP] could not bind to /ff02:0:0:0:0:1:2:3 (IPv6 address); make sure your mcast_addr is of the same type as the IP stack (IPv4 or IPv6), by checking the value of the system property java.net.preferIPv4Stack. Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details).
Exception was: java.net.SocketException: Invalid argument


> Binding to mcast address in UDP.java is not working on Linux with IPv6
> ----------------------------------------------------------------------
>
>                 Key: JGRP-956
>                 URL: https://jira.jboss.org/jira/browse/JGRP-956
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> On Linux and Solaris platforms, when setting up the main multicast receiver socket, Bela allows binding the socket to its multicast address, like this:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> SocketAddress group_sock_addr = new InetSocketAddress(group_addr, port) ;
> MulticastSocket s = new MulticastSocket(group_sock_addr) ;    // funny
> s.joinGroup(group_addr) ;
> Binding to the multicast address on Linux and Solaris was done in order to avoid the promiscuous traffic problem. A detailed discussion on the matter can be found in the bugzilla report:https://bugzilla.redhat.com/show_bug.cgi?id=231899. 
> This works on Linux with IPv4 but is not working on Linux with IPv6 for the multicast-address ff02::1 - an error message is being generated (SocketException, invalid argument) and  the code then tries to create the same multicast address in the usual way:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> MulticastSocket s = new MulticastSocket(port) ;
> s.setInterface(bind_addr) ;
> s.joinGroup(group_addr) ;
> This is only a problem in that it generates a confusing error message about using mixed IPv4 / IPv6 stacks, but the socket continues to work correctly as far as I can tell.
> Haven't confirmed this, but I believe the promiscuous traffic issue does not arise with IPv6 multicast sockets.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 12:16:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 12:16:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-956) Binding to mcast
 address in UDP.java is not working on Linux with IPv6
In-Reply-To: <3739279.1239718822407.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1569845658.1247760989418.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476580#action_12476580 ] 

Richard Achmatowicz commented on JGRP-956:
------------------------------------------

The confusing error message which is generated when we try to bind to IPv6 multicast address is:
16:35:19,970 INFO [DefaultPartition] Initializing partition DefaultPartition
16:35:20,231 WARN [UDP] could not bind to /ff02:0:0:0:0:1:2:3 (IPv6 address); make sure your mcast_addr is of the same type as the IP stack (IPv4 or IPv6).
Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details).
Exception was: java.net.SocketException: Invalid argument
16:35:20,289 INFO [STDOUT]
---------------------------------------------------------
GMS: address is fe80:0:0:0:215:17ff:fe2d:6821:44270 (cluster=DefaultPartition)
---------------------------------------------------------

It turns out that this message is confusing, but entirely accurate. This exception occurs when three conditions are present:
(i) we pass an IPv6 multicast address
(ii) we try to bind to the multicast socket formed from multicast address and multicast port
(iii) we prefer the IPv4 stack using java.net.preferIPv4Stack=true

After the exception
java.net.SocketException: Invalid argument               (i.e. you're trying to bind an IPv6 mcast address to an IPv4 stack)
the code will then try to bind only to the multicast port and it is indeed the case that when we bind to the multicast port only in IPv6, we do get crosstalk.


> Binding to mcast address in UDP.java is not working on Linux with IPv6
> ----------------------------------------------------------------------
>
>                 Key: JGRP-956
>                 URL: https://jira.jboss.org/jira/browse/JGRP-956
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> On Linux and Solaris platforms, when setting up the main multicast receiver socket, Bela allows binding the socket to its multicast address, like this:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> SocketAddress group_sock_addr = new InetSocketAddress(group_addr, port) ;
> MulticastSocket s = new MulticastSocket(group_sock_addr) ;    // funny
> s.joinGroup(group_addr) ;
> Binding to the multicast address on Linux and Solaris was done in order to avoid the promiscuous traffic problem. A detailed discussion on the matter can be found in the bugzilla report:https://bugzilla.redhat.com/show_bug.cgi?id=231899. 
> This works on Linux with IPv4 but is not working on Linux with IPv6 for the multicast-address ff02::1 - an error message is being generated (SocketException, invalid argument) and  the code then tries to create the same multicast address in the usual way:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> MulticastSocket s = new MulticastSocket(port) ;
> s.setInterface(bind_addr) ;
> s.joinGroup(group_addr) ;
> This is only a problem in that it generates a confusing error message about using mixed IPv4 / IPv6 stacks, but the socket continues to work correctly as far as I can tell.
> Haven't confirmed this, but I believe the promiscuous traffic issue does not arise with IPv6 multicast sockets.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 12:32:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 12:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <403032961.1247761949113.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476587#action_12476587 ] 

Richard Achmatowicz commented on JGRP-1011:
-------------------------------------------

Testing for the release usually involves the following set of tests:
(i) run the unit/functional tests (unittests-xml)
(ii) run the non-unit tests against udp (all-tests-udp)
(iii) run the non-unit tests against tcp (all-tests-tcp)
(iv) run the manual tests

These tests are usually run against IPv4 non-loopback addresses.
However, this time, I will run the tests against 
a) IPv4 loopback addresses 
b) IPv4 non-loopback addresses
c) IPv6 loopback addresses 
d) IPv6 non-loopback, global addresses

The configs used are as follows:

// IPv4 loopback
jgroups.bind_addr=127.0.0.1
jgroups.tcpping.initial_hosts=127.0.0.1[7800]
jgroups.udp.mcast_addr=232.15.15.15
jgroups.udp.mcast_port=45588
jgroups.udp.ip_ttl=5
jgroups.tunnel.router_host=127.0.0.1
jgroups.tunnel.router_port=12001
# use true for IPv6 and false for IPv4 
jgroups.useIPv6=false

// IPv4 non-loopback
jgroups.bind_addr=192.168.2.12
jgroups.tcpping.initial_hosts=192.168.2.12[7800]
jgroups.udp.mcast_addr=232.15.15.15
jgroups.udp.mcast_port=45588
jgroups.udp.ip_ttl=5
jgroups.tunnel.router_host=192.168.2.12
jgroups.tunnel.router_port=12001
# use true for IPv6 and false for IPv4 
jgroups.useIPv6=false

// IPv6 loopback
jgroups.bind_addr=::1
jgroups.tcpping.initial_hosts=::1[7800]
jgroups.udp.mcast_addr=ff01::1
jgroups.udp.mcast_port=45588
jgroups.udp.ip_ttl=5
jgroups.tunnel.router_host=::1
jgroups.tunnel.router_port=12001
# use true for IPv6 and false for IPv4 
jgroups.useIPv6=true

// IPv6 non-loopback
jgroups.bind_addr=3ffe:ffff:0100:f101::1
jgroups.tcpping.initial_hosts=3ffe:ffff:0100:f101::1[7800]
jgroups.udp.mcast_addr=ff0e::1:2:3
jgroups.udp.mcast_port=45588
jgroups.udp.ip_ttl=5
jgroups.tunnel.router_host=3ffe:ffff:0100:f101::1
jgroups.tunnel.router_port=12001
# use true for IPv6 and false for IPv4 
jgroups.useIPv6=true



> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 12:06:41 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 16 Jul 2009 12:06:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1605) management
 API needs a portable and complete serialization format
In-Reply-To: <1388356.1240496381566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1717522063.1247760401568.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned JBMESSAGING-1605:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> management API needs a portable and complete serialization format
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-1605
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1605
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>         Attachments: patch-JBMESSAGING-1605.txt
>
>
> to work in a replicated environment; JBoss Messaging needs a Management API which requires complex parameter. E.g.
> public void createConnectionFactory(String name,
>                                        List<Pair<TransportConfiguration, TransportConfiguration>> connectorConfigs,
>                                        String connectionLoadBalancingPolicyClassName,
>                                        long pingPeriod,
>                                        ...);
> TransportConfiguration also contains a Map<String, Object> of parameters.
> Currently, the management code does not allow for such complex API. It only works with simple types (primitives + Strings) and String[].
> Moreover, the management API returns results (attribute values or operations results) serialized using Java serialization which won't be portable on other platforms.
> We need to define a encoding format for Management API that allow complex parameters and be portable.
> One idea'd be to use JSON[1] for that (JSON for Java is 7 classes[2] we could import in JBM source code).
> With that, the management operations would be composed of a JSON string containing:
> - the name of the resource
> - the name of the operation
> - an orderded list of the parameters (as complex as they are)
> When JBM receives a management operations, it must decode the JSON strings and find the relevant methods to call.
> There is an issue here, JSON does not contain any information on the types of parameters.
> One solution is to add the parameter type in the JSON string (e.g. this JSON object can be decoded as a TransportConfiguration class) but it add extra burden on the client sending the message and is not well suited for portability reason.
> Another solution would be to add an additional layer on the server side.
> When a management message is received, we extract the name of the resource, the operation name and the number of parameters of the operation.
> We'd have a mapper which will know based on this information what method should be called on the resource and cast the parameters from JSON to the appropriate types (e.g. Boolean, String, int but also TransportConfiguration).
> The only constraint this solution have is that there must not be 2 methods on the same resource, with the same name and the same number of parameters. The cardinality of the methods must differ to be able to identify it uniquely. If the methods have the same numbers of parameters, they must have different names (e.g. createConnectionFactoryWithDiscoveryGroup() vs. createConnectionFactory() which takes a List of Pair of TransportConfiguration)
> For return type, we could return a JSON String containing the result. This would allow for complex results (similar to CompositeData and TabularData from JMX).
> [1] http://www.json.org/
> [2] http://www.json.org/java

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 12:14:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 16 Jul 2009 12:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-956) Binding to mcast
 address in UDP.java is not working on Linux with IPv6
In-Reply-To: <3739279.1239718822407.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1937328907.1247760869330.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476578#action_12476578 ] 

Richard Achmatowicz commented on JGRP-956:
------------------------------------------

Well, it turns out that it is possible to bind to IPv6 multicast addresses, that it does not lead to crosstalk when we do so, and that this jira issue was the result of incorrect coding of the Java system property java.net.preferIPv6Stack.

I modified Brian's promiscuous.jar so that it took an additional boolean parameter: true -> bind to multicast socket; false -> bind to multicast port only.

So, in the case of IPv4 addresses, we can bind to port only:
$ java -jar promiscuoustraffic.jar 192.168.2.12 192.168.2.12 230.10.11.12 230.10.11.13 64000 1 false
setting up sender socket with address /192.168.2.12
setting up good receiver socket with address /230.10.11.12
binding mcast socket to port:64000
setting up bad receiver socket with address /230.10.11.13
binding mcast socket to port:64000
Listening on address /230.10.11.12
Listening on address /230.10.11.13
Sending 'Hello' on /230.10.11.12:64000
/230.10.11.13:64000 -- Received Hello
/230.10.11.12:64000 -- Received Hello
Bad news. Detected the Promiscuous Traffic problem. Received Hello on undesired address /230.10.11.13

Or we can bind to multicast address:
$ java -Djava.net.preferIPv4Stack=true -jar promiscuoustraffic.jar 192.168.2.12 192.168.2.12 230.10.11.12 230.10.11.13 64000 1 true
setting up sender socket with address /192.168.2.12
setting up good receiver socket with address /230.10.11.12
binding mcast socket to address:/230.10.11.12:64000
setting up bad receiver socket with address /230.10.11.13
binding mcast socket to address:/230.10.11.13:64000
Listening on address /230.10.11.12
Listening on address /230.10.11.13
Sending 'Hello' on /230.10.11.12:64000
/230.10.11.12:64000 -- Received Hello
Good news. Did not detect the Promiscuous Traffic problem.


We can now show that promiscuous traffic does not occur when binding to multicast address on Fedora 8 with JDK 5:

$ java -jar promiscuoustraffic.jar 3ffe:ffff:100:f101::1 3ffe:ffff:100:f101::1 ff0e::1:2:2 ff0e::1:2:3 64000 1 true
setting up sender socket with address /3ffe:ffff:100:f101:0:0:0:1
setting up good receiver socket with address /ff0e:0:0:0:0:1:2:2
binding mcast socket to address:/ff0e:0:0:0:0:1:2:2:64000
setting up bad receiver socket with address /ff0e:0:0:0:0:1:2:3
binding mcast socket to address:/ff0e:0:0:0:0:1:2:3:64000
Listening on address /ff0e:0:0:0:0:1:2:2
Listening on address /ff0e:0:0:0:0:1:2:3
Sending 'Hello' on /ff0e:0:0:0:0:1:2:2:64000
/ff0e:0:0:0:0:1:2:2:64000 -- Received Hello
Good news. Did not detect the Promiscuous Traffic problem.

and that if we prefer the IPv4 stack with an IPv6 mcast address, we get the exception above:

$ java -Djava.net.preferIPv4Stack=true -jar promiscuoustraffic.jar 3ffe:ffff:100:f101::1 3ffe:ffff:100:f101::1 ff0e::1:2:3 ff0e::1:2:4 64000 0
setting up sender socket with address /3ffe:ffff:100:f101:0:0:0:1
setting up good receiver socket with address /ff0e:0:0:0:0:1:2:3
binding mcast socket to port:64000
java.net.SocketException: Invalid argument
        at java.net.PlainDatagramSocketImpl.join(Native Method)
        at java.net.PlainDatagramSocketImpl.join(PlainDatagramSocketImpl.java:172)
        at java.net.MulticastSocket.joinGroup(MulticastSocket.java:276)
        at org.jboss.test.cluster.test.PromiscuousTrafficTester$MulticastReceiver.<init>(PromiscuousTrafficTester.java:222)
        at org.jboss.test.cluster.test.PromiscuousTrafficTester.setUpSockets(PromiscuousTrafficTester.java:144)
        at org.jboss.test.cluster.test.PromiscuousTrafficTester.<init>(PromiscuousTrafficTester.java:67)
        at org.jboss.test.cluster.test.PromiscuousTrafficTester.main(PromiscuousTrafficTester.java:191)

Promiscuous traffic does occur if we bind to multicast port only:
$ java -jar promiscuoustraffic.jar 3ffe:ffff:100:f101::1 3ffe:ffff:100:f101::1 ff0e::1:2:3 ff0e::1:2:4 64000 0setting up sender socket with address /3ffe:ffff:100:f101:0:0:0:1
setting up good receiver socket with address /ff0e:0:0:0:0:1:2:3
binding mcast socket to port:64000
setting up bad receiver socket with address /ff0e:0:0:0:0:1:2:4
binding mcast socket to port:64000
Listening on address /ff0e:0:0:0:0:1:2:3
Listening on address /ff0e:0:0:0:0:1:2:4
Sending 'Hello' on /ff0e:0:0:0:0:1:2:3:64000
/ff0e:0:0:0:0:1:2:4:64000 -- Received Hello
/ff0e:0:0:0:0:1:2:3:64000 -- Received Hello
Bad news. Detected the Promiscuous Traffic problem. Received Hello on undesired address /ff0e:0:0:0:0:1:2:4


> Binding to mcast address in UDP.java is not working on Linux with IPv6
> ----------------------------------------------------------------------
>
>                 Key: JGRP-956
>                 URL: https://jira.jboss.org/jira/browse/JGRP-956
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 2.8
>
>
> On Linux and Solaris platforms, when setting up the main multicast receiver socket, Bela allows binding the socket to its multicast address, like this:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> SocketAddress group_sock_addr = new InetSocketAddress(group_addr, port) ;
> MulticastSocket s = new MulticastSocket(group_sock_addr) ;    // funny
> s.joinGroup(group_addr) ;
> Binding to the multicast address on Linux and Solaris was done in order to avoid the promiscuous traffic problem. A detailed discussion on the matter can be found in the bugzilla report:https://bugzilla.redhat.com/show_bug.cgi?id=231899. 
> This works on Linux with IPv4 but is not working on Linux with IPv6 for the multicast-address ff02::1 - an error message is being generated (SocketException, invalid argument) and  the code then tries to create the same multicast address in the usual way:
> InetAddress group_addr = ...
> InetAddress bind_addr = ...
> MulticastSocket s = new MulticastSocket(port) ;
> s.setInterface(bind_addr) ;
> s.joinGroup(group_addr) ;
> This is only a problem in that it generates a confusing error message about using mixed IPv4 / IPv6 stacks, but the socket continues to work correctly as far as I can tell.
> Haven't confirmed this, but I believe the promiscuous traffic issue does not arise with IPv6 multicast sockets.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 16:30:29 2009
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Mon, 20 Jul 2009 16:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7110)
 ClusterPartition.ThreadGate can block shutdown of AS
Message-ID: <1909704028.1248121829865.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

ClusterPartition.ThreadGate can block shutdown of AS
----------------------------------------------------

                 Key: JBAS-7110
                 URL: https://jira.jboss.org/jira/browse/JBAS-7110
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


The following stack trace appears in a thread dump, after a failure to shutdown the AS within the testsuite:

Thread: JBoss Shutdown Hook : priority:5, demon:true, threadId:11, threadState:TIMED_WAITING
- waiting on <0x1d7ada9> (a org.jboss.ha.framework.server.ClusterPartition$ThreadGate)
java.lang.Object.wait(Native Method)
org.jboss.ha.framework.server.ClusterPartition$ThreadGate.await(ClusterPartition.java:2381)
org.jboss.ha.framework.server.ClusterPartition.callAsynchMethodOnCluster(ClusterPartition.java:1325)
org.jboss.ha.framework.server.DistributedReplicantManagerImpl.remove(DistributedReplicantManagerImpl.java:448)
org.jboss.profileservice.cluster.repository.DefaultRepositoryClusteringHandler.shutdown(DefaultRepositoryClusteringHandler.java:275)
org.jboss.system.server.profileservice.repository.clustered.ClusteredDeploymentRepository.unload(ClusteredDeploymentRepository.java:459)
org.jboss.system.server.profile.repository.AbstractProfile.destroy(AbstractProfile.java:163)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:97)
org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:77)
org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.uninstall(AbstractProfileLifeCycleAction.java:57)
org.jboss.system.server.profileservice.repository.AbstractProfileAction.uninstall(AbstractProfileAction.java:70)
org.jboss.system.server.profileservice.repository.AbstractProfileService.uninstall(AbstractProfileService.java:417)
org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1665)
org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1276)
org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1180)
org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1235)
org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1180)
org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1235)
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:828)
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
org.jboss.system.server.profileservice.repository.AbstractProfileService.deactivateProfile(AbstractProfileService.java:448)
org.jboss.system.server.profileservice.ProfileServiceBootstrap.deactivateProfiles(ProfileServiceBootstrap.java:381)
org.jboss.system.server.profileservice.ProfileServiceBootstrap.shutdown(ProfileServiceBootstrap.java:339)
org.jboss.bootstrap.AbstractServerImpl.shutdownServer(AbstractServerImpl.java:571)
org.jboss.bootstrap.AbstractServerImpl$ShutdownHook.run(AbstractServerImpl.java:909)

The root cause is a bug in ThreadGate.await(long), which does not correctly return if the timeout value is reached while the gate is still closed.

This same issue was found and fixed in JBC.  See JBCACHE-1173.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 11:46:29 2009
From: jira-events at lists.jboss.org (Tihomir Surdilovic (JIRA))
Date: Thu, 16 Jul 2009 11:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2060) change package
 format in drools-ant-tests from .dpkg to .pkg
In-Reply-To: <6008222.1239823702637.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <380215583.1247759189213.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tihomir Surdilovic resolved JBRULES-2060.
-----------------------------------------

    Fix Version/s: 5.0.2
       Resolution: Done


resolved

> change package format in drools-ant-tests from .dpkg to .pkg
> ------------------------------------------------------------
>
>                 Key: JBRULES-2060
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2060
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-ant
>            Reporter: Tihomir Surdilovic
>            Assignee: Tihomir Surdilovic
>             Fix For: 5.0.2
>
>
> drools-ant-tests example build file for binformat="package" creates .dpkg extension. This should follow the "standard" .pkg extension. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 12:00:29 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 16 Jul 2009 12:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7104) Typo in windows
 run.bat prevents inclusion of tools.jar
In-Reply-To: <261786877.1247752482824.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <533233057.1247760029312.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved JBAS-7104.
--------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1
       Resolution: Done


Typo is fixed in Branch_5_x + trunk.  

> Typo in windows run.bat prevents inclusion of tools.jar
> -------------------------------------------------------
>
>                 Key: JBAS-7104
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7104
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Kevin Conner
>            Assignee: Scott Marlow
>            Priority: Trivial
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Just noticed the following in the windows run.bat while investigating an issue.
>   if "x%JAVAC_JAR%" == "x" (
>     set "RUNJAR=%JAVAC_JAR%;%JBOSS_HOME%\bin\run.jar"
>   ) else (
>     set "RUNJAR=%JBOSS_HOME%\bin\run.jar"
>   )
> The set commands should be reversed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 11:31:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Thu, 16 Jul 2009 11:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1686) Add more
 transactional options for the JCA adapter
Message-ID: <301051903.1247758289359.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add more transactional options for the JCA adapter
--------------------------------------------------

                 Key: JBMESSAGING-1686
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1686
             Project: JBoss Messaging
          Issue Type: Feature Request
            Reporter: Clebert Suconic
            Assignee: Clebert Suconic
             Fix For: 2.0.0


It should be possible to configure transactions for MDBs in a better fashion. Like receiving messages non-transactionally, or batching a number of transactions, even if this would mean non-compliant but activated by the user's choice.



We already have:
- Local Transaction
- XA Transaction


The options I'm thinking:
We should add:


- Batching transactions (commit on every X records... like most users do when processing a high number of messages outside the application server)
- NonTransactional (messages being received non transactionally.. what should be good for Non Persistent Messages)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 11:50:29 2009
From: jira-events at lists.jboss.org (Kevin Conner (JIRA))
Date: Thu, 16 Jul 2009 11:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7104) Typo in windows
 run.bat prevents inclusion of tools.jar
In-Reply-To: <261786877.1247752482824.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <502917765.1247759429845.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476573#action_12476573 ] 

Kevin Conner commented on JBAS-7104:
------------------------------------

We embed wise within the ESB (SOA platform) and this requires the compiler to compile WS proxies.  Not an ideal situation but one we need for now.

> Typo in windows run.bat prevents inclusion of tools.jar
> -------------------------------------------------------
>
>                 Key: JBAS-7104
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7104
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Kevin Conner
>            Assignee: Scott Marlow
>            Priority: Trivial
>
> Just noticed the following in the windows run.bat while investigating an issue.
>   if "x%JAVAC_JAR%" == "x" (
>     set "RUNJAR=%JAVAC_JAR%;%JBOSS_HOME%\bin\run.jar"
>   ) else (
>     set "RUNJAR=%JBOSS_HOME%\bin\run.jar"
>   )
> The set commands should be reversed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 11:11:43 2009
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 16 Jul 2009 11:11:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7104) Typo in windows
 run.bat prevents inclusion of tools.jar
In-Reply-To: <261786877.1247752482824.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1712398080.1247757103209.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476567#action_12476567 ] 

Scott Marlow commented on JBAS-7104:
------------------------------------

Yes, this is clearly a typo.  What is the impact of not having the Java compiler on the system classpath when starting the as?  Is this impacting Tomcat jsp compiling?  I'm just curious what the issue was.

> Typo in windows run.bat prevents inclusion of tools.jar
> -------------------------------------------------------
>
>                 Key: JBAS-7104
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7104
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Kevin Conner
>            Assignee: Scott Marlow
>            Priority: Trivial
>
> Just noticed the following in the windows run.bat while investigating an issue.
>   if "x%JAVAC_JAR%" == "x" (
>     set "RUNJAR=%JAVAC_JAR%;%JBOSS_HOME%\bin\run.jar"
>   ) else (
>     set "RUNJAR=%JBOSS_HOME%\bin\run.jar"
>   )
> The set commands should be reversed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 10:49:40 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 16 Jul 2009 10:49:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1670) Disallow
 forward slashes in jms destinations
In-Reply-To: <15439568.1246092776416.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <633708526.1247755780980.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned JBMESSAGING-1670:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> Disallow forward slashes in jms destinations
> --------------------------------------------
>
>                 Key: JBMESSAGING-1670
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1670
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> We need to disallow forward slashes in JMS destination names since they won't be able to be deployed in JNDI since the slash will be interperted as a subcontext by JNDI

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 10:16:42 2009
From: jira-events at lists.jboss.org (Prabhat Jha (JIRA))
Date: Thu, 16 Jul 2009 10:16:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2433) Portlet
 Instance creation problem, when new portlet is deployed
In-Reply-To: <1003923183.1247753369204.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <127693052.1247753802882.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476561#action_12476561 ] 

Prabhat Jha commented on JBPORTAL-2433:
---------------------------------------

Hi Vijay,

Did you search and discuss this in portal user forum? If so, please comment with forum URL. Otherwise, please start a thread in forum. It's not a good idea to create a jira issue for every problem right away without first verifying if it's a bug or limitation of product

> Portlet Instance creation problem, when new portlet is deployed 
> ----------------------------------------------------------------
>
>                 Key: JBPORTAL-2433
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2433
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.7.0 Final
>         Environment: Tested in Windows and Linux OS
>            Reporter: vijay chaudhry
>             Fix For: 2.7.0 Final
>
>
> Take the scenario, I have created a portlet DemoPortlet with instance name DemoPortletInstance.
> Now I decided to undeploy the DemoPortlet.war file and Again I created one more Portlet with name TestPortlet and here I created the Instance name as DemoPortletInstance. Which is same as above portlet which I already undeployed.
> Now what is there on the admin screen. Portlet definition is created correctly but Portlet Instance is not displayed under Portlet Instances tab under Admin tab. Now If I try to create the instance name DemoPortletInstance manually then it is not creating that instance and in logs it says that instance already exists.
> But I cann't use that instance in the application.
> I think it is bug.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 10:51:29 2009
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 16 Jul 2009 10:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7104) Typo in windows
 run.bat prevents inclusion of tools.jar
In-Reply-To: <261786877.1247752482824.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <835489940.1247755889190.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dimitris Andreadis reassigned JBAS-7104:
----------------------------------------

    Assignee: Scott Marlow


> Typo in windows run.bat prevents inclusion of tools.jar
> -------------------------------------------------------
>
>                 Key: JBAS-7104
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7104
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Kevin Conner
>            Assignee: Scott Marlow
>            Priority: Trivial
>
> Just noticed the following in the windows run.bat while investigating an issue.
>   if "x%JAVAC_JAR%" == "x" (
>     set "RUNJAR=%JAVAC_JAR%;%JBOSS_HOME%\bin\run.jar"
>   ) else (
>     set "RUNJAR=%JBOSS_HOME%\bin\run.jar"
>   )
> The set commands should be reversed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 10:09:29 2009
From: jira-events at lists.jboss.org (vijay chaudhry (JIRA))
Date: Thu, 16 Jul 2009 10:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2433) Portlet Instance
 creation problem, when new portlet is deployed
Message-ID: <1003923183.1247753369204.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Portlet Instance creation problem, when new portlet is deployed 
----------------------------------------------------------------

                 Key: JBPORTAL-2433
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2433
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Portlet
    Affects Versions: 2.7.0 Final
         Environment: Tested in Windows and Linux OS
            Reporter: vijay chaudhry
             Fix For: 2.7.0 Final



Take the scenario, I have created a portlet DemoPortlet with instance name DemoPortletInstance.
Now I decided to undeploy the DemoPortlet.war file and Again I created one more Portlet with name TestPortlet and here I created the Instance name as DemoPortletInstance. Which is same as above portlet which I already undeployed.

Now what is there on the admin screen. Portlet definition is created correctly but Portlet Instance is not displayed under Portlet Instances tab under Admin tab. Now If I try to create the instance name DemoPortletInstance manually then it is not creating that instance and in logs it says that instance already exists.
But I cann't use that instance in the application.

I think it is bug.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 18 20:59:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Sat, 18 Jul 2009 20:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6919) Ensure each AS
 Service removes all of its Threads after undeployment / Server Shutdown
In-Reply-To: <30283171.1242320566711.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1031624730.1247965169274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated JBAS-6919:
--------------------------------------

    Summary: Ensure each AS Service removes all of its Threads after undeployment / Server Shutdown  (was: Ensure each AS Service leaves only Daemon Threads after Server shutdown)


> Ensure each AS Service removes all of its Threads after undeployment / Server Shutdown
> --------------------------------------------------------------------------------------
>
>                 Key: JBAS-6919
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6919
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>         Attachments: thread_dumps_after_server_shutdown.txt
>
>
> Container task.
> Server.shutdown() must take down all non-Daemon Threads run during the start lifecycle, else the VM won't be able to exit without an explicit call to Runtime.exit().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 09:54:42 2009
From: jira-events at lists.jboss.org (Kevin Conner (JIRA))
Date: Thu, 16 Jul 2009 09:54:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7104) Typo in windows
 run.bat prevents inclusion of tools.jar
Message-ID: <261786877.1247752482824.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Typo in windows run.bat prevents inclusion of tools.jar
-------------------------------------------------------

                 Key: JBAS-7104
                 URL: https://jira.jboss.org/jira/browse/JBAS-7104
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Kevin Conner
            Priority: Trivial


Just noticed the following in the windows run.bat while investigating an issue.

  if "x%JAVAC_JAR%" == "x" (
    set "RUNJAR=%JAVAC_JAR%;%JBOSS_HOME%\bin\run.jar"
  ) else (
    set "RUNJAR=%JBOSS_HOME%\bin\run.jar"
  )

The set commands should be reversed.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 09:23:29 2009
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 16 Jul 2009 09:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-218) Requires property
 order even when maked as choice
Message-ID: <305663886.1247750609279.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Requires property order even when maked as choice
-------------------------------------------------

                 Key: JBXB-218
                 URL: https://jira.jboss.org/jira/browse/JBXB-218
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-2.0.1.GA
            Reporter: Thomas Diesler


Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Property order is not specified for type org.jboss.osgi.blueprint.parser.xb.TReferenceListener bound to a sequence. Property order can be specified using @XmlType.propOrder or @XmlAccessorOrder. List of properties: bean any reference refElement
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.assertPropOrderNotRequired(JBossXBNoSchemaBuilder.java:1278)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1071)
	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)

@XmlType(name = "TreferenceListener", namespace = BlueprintContext.XMLNS_BLUEPRINT)
public class TReferenceListener extends GTargetComponent

@XmlType(name = "GtargetComponent", namespace = BlueprintContext.XMLNS_BLUEPRINT)
@JBossXmlModelGroup(kind = JBossXmlConstants.MODEL_GROUP_CHOICE)
public class GTargetComponent extends TComponent

https://anonsvn.jboss.org/repos/jbossas/projects/jboss-osgi/trunk/reactor/bundles/blueprint/impl/src/main/java/org/jboss/osgi/blueprint/parser/xb/TReferenceListener.java

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 09:23:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 16 Jul 2009 09:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-210) Property order cannot
 be defined on super type
In-Reply-To: <1151868256.1246624731398.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <442398125.1247750609208.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBXB-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin updated JBXB-210:
-----------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244079#4244079


> Property order cannot be defined on super type
> ----------------------------------------------
>
>                 Key: JBXB-210
>                 URL: https://jira.jboss.org/jira/browse/JBXB-210
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Thomas Diesler
>
> Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Property order is not specified for type org.jboss.osgi.blueprint.parser.xb.TReference bound to a sequence. Property order can be specified using @XmlType.propOrder or @XmlAccessorOrder. List of properties: referenceListeners dependsOn initialization componentName description any interfaceNames otherAttributes timeout filter availability
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.assertPropOrderNotRequired(JBossXBNoSchemaBuilder.java:1278)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1071)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:767)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:523)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:482)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1684)
> @XmlType(name = "Treference", namespace = BlueprintContext.XMLNS_BLUEPRINT)
> public class TReference extends TServiceReference
> @XmlType(name = "TserviceReference", namespace = BlueprintContext.XMLNS_BLUEPRINT, propOrder = { "description" })
> public class TServiceReference extends TComponent

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 06:18:29 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 06:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-355) offer conversion
 support for files from jBPM 3 to jBPM 4
In-Reply-To: <1159827641.1246892871401.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <927961951.1247739509306.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-355:
----------------------------

    Fix Version/s: jBPM jPDL Designer 4.1
                       (was: jBPM jPDL Designer 4.x)
         Priority: Optional  (was: Minor)


> offer conversion support for files from jBPM 3 to jBPM 4
> --------------------------------------------------------
>
>                 Key: GPD-355
>                 URL: https://jira.jboss.org/jira/browse/GPD-355
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>            Priority: Optional
>             Fix For: jBPM jPDL Designer 4.1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 06:06:29 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 06:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (GPD-339) pageflow designer
In-Reply-To: <18436103.1242895977551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <84800396.1247738789836.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/GPD-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476528#action_12476528 ] 

Tom Baeyens commented on GPD-339:
---------------------------------

this only needs to be done if there are new pageflow designer requests.

as long as pageflow language in seam remains the same, the old pageflow designer can be used as is.

> pageflow designer
> -----------------
>
>                 Key: GPD-339
>                 URL: https://jira.jboss.org/jira/browse/GPD-339
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: seam
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.x
>
>
> new version of the pageflow designer

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 06:18:29 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 06:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-336) image generation fails
In-Reply-To: <18908917.1242894356480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1995508699.1247739509430.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-336:
----------------------------

    Fix Version/s: jBPM jPDL Designer 4.1
                       (was: jBPM jPDL Designer 4.x)
         Priority: Optional  (was: Minor)


> image generation fails
> ----------------------
>
>                 Key: GPD-336
>                 URL: https://jira.jboss.org/jira/browse/GPD-336
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>            Priority: Optional
>             Fix For: jBPM jPDL Designer 4.1
>
>
> image generation seems to work for org.jbpm.examples.async.activity
> but it seems to fail for org.jbpm.examples.async.fork.  in that case I get an image with only a diagonal line.
> koen, do you get the same with that example ?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 06:10:29 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 06:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-359) Events attached to
	activities
In-Reply-To: <1291966959.1247643029123.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <739626004.1247739029562.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-359:
----------------------------

    Description: This means adding the capability of the gpd to place BPMN events on the border of activities.


> Events attached to activities 
> ------------------------------
>
>                 Key: GPD-359
>                 URL: https://jira.jboss.org/jira/browse/GPD-359
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.x
>
>
> This means adding the capability of the gpd to place BPMN events on the border of activities.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 05:58:29 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 05:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-361) analyse impact of jpdl
 changes on gpd
In-Reply-To: <70239015.1247735982202.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1116028518.1247738309237.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-361:
----------------------------

    Due Date: 21/Aug/09


> analyse impact of jpdl changes on gpd
> -------------------------------------
>
>                 Key: GPD-361
>                 URL: https://jira.jboss.org/jira/browse/GPD-361
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>            Reporter: Tom Baeyens
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.1
>
>
> what type of changes can we have in jpdl that affect the gpd ?
> how will gpd deal with these changes ?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 05:19:42 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 05:19:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-361) analyse impact of jpdl
 changes on gpd
Message-ID: <70239015.1247735982202.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

analyse impact of jpdl changes on gpd
-------------------------------------

                 Key: GPD-361
                 URL: https://jira.jboss.org/jira/browse/GPD-361
             Project: JBoss jBPM GPD
          Issue Type: Task
            Reporter: Tom Baeyens
            Assignee: Koen Aers
             Fix For: jBPM jPDL Designer 4.1


what type of changes can we have in jpdl that affect the gpd ?
how will gpd deal with these changes ?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 05:56:30 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 05:56:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-353) contribute xsd to xml
 catalog (xsd dependent on runtime)
In-Reply-To: <22572021.1244570156492.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1430302545.1247738190201.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-353:
----------------------------

    Due Date: 07/Aug/09


> contribute xsd to xml catalog (xsd dependent on runtime)
> --------------------------------------------------------
>
>                 Key: GPD-353
>                 URL: https://jira.jboss.org/jira/browse/GPD-353
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.1
>
>
> this has to happen when the jBPM runtime is configured in the general jBPM preferences

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 05:34:29 2009
From: jira-events at lists.jboss.org (Alexander Lengson (JIRA))
Date: Thu, 16 Jul 2009 05:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7103) Hot deployment woks
 incorrectly on the EE project without deployment descriptors
Message-ID: <1370254810.1247736869351.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Hot deployment woks incorrectly on the EE project without deployment descriptors
--------------------------------------------------------------------------------

                 Key: JBAS-7103
                 URL: https://jira.jboss.org/jira/browse/JBAS-7103
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Deployers
    Affects Versions: JBossAS-5.0.1.GA
         Environment: Windows XP SP3 
JBoss AS: 5.0.1.GA
Eclipse 3.5: eclipse-jee-galileo-win32.zip 
JBossTools : 3.0.1.GA JBossTools-ALL-win32-3.0.1.GA-R200905070146-H18.zip 

            Reporter: Alexander Lengson
            Assignee: Ales Justin


JBoss AS 5.0.1.GA does not redeploy new EJB written over old one when EJB JAR does not contain deployment descriptors and EJB is deployed as an exploded folder, not single-file archive.
As discussed in another issue (https://jira.jboss.org/jira/browse/JBIDE-4608), this is because of JBoss AS redeploys EJB if its descriptor is touched. Simple changing .class file is not enough to make JBoss redeploy the EJB, but in the case when there is no deployment descriptor (everything is configured via annotations), nothing may cause redeploy (except full remove and new publish)

Workaround is to have deployment descriptors in the module.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 05:56:30 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 05:56:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-353) contribute xsd to xml
 catalog (xsd dependent on runtime)
In-Reply-To: <22572021.1244570156492.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1976155975.1247738190125.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-353:
----------------------------

    Description: this has to happen when the jBPM runtime is configured in the general jBPM preferences


> contribute xsd to xml catalog (xsd dependent on runtime)
> --------------------------------------------------------
>
>                 Key: GPD-353
>                 URL: https://jira.jboss.org/jira/browse/GPD-353
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.1
>
>
> this has to happen when the jBPM runtime is configured in the general jBPM preferences

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 05:39:29 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 05:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-358) Create jBPM Project
 Configuration Wizard
In-Reply-To: <497794165.1247499509147.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <91101615.1247737169390.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-358:
----------------------------

    Fix Version/s: jBPM jPDL Designer 4.x
                       (was: jBPM jPDL Designer 4.1)


> Create jBPM Project Configuration Wizard
> ----------------------------------------
>
>                 Key: GPD-358
>                 URL: https://jira.jboss.org/jira/browse/GPD-358
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.x
>
>
> This wizard can be launched from the project popup menu in the Java/J2EE/Resources perspective. It will import all the libraries from the currently configured runtime.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 05:37:29 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 05:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-357) Error while validating
 jPDL file: Problem class was moved from API
In-Reply-To: <985295068.1247498249570.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2003035359.1247737049132.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-357:
----------------------------

       Due Date: 24/Jul/09
    Description: 
1) Fix the dynamic loading problem of the problem class that has moved

2) Add automatic validation activation in the background


> Error while validating jPDL file: Problem class was moved from API
> ------------------------------------------------------------------
>
>                 Key: GPD-357
>                 URL: https://jira.jboss.org/jira/browse/GPD-357
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM jPDL Designer 4.0.0.GA
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.1
>
>
> 1) Fix the dynamic loading problem of the problem class that has moved
> 2) Add automatic validation activation in the background

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 05:54:29 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 05:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-358) Create jBPM Project
 Configuration Wizard
In-Reply-To: <497794165.1247499509147.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2073646231.1247738069497.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-358:
----------------------------

    Description: 
This wizard can be launched from the project popup menu in the Java/J2EE/Resources perspective. 

A project configuration will offered and includes
 - a selection of the configured jBPM runtimes
 - a checkbox to import all the jBPM Libraries

  was:This wizard can be launched from the project popup menu in the Java/J2EE/Resources perspective. It will import all the libraries from the currently configured runtime.



> Create jBPM Project Configuration Wizard
> ----------------------------------------
>
>                 Key: GPD-358
>                 URL: https://jira.jboss.org/jira/browse/GPD-358
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.x
>
>
> This wizard can be launched from the project popup menu in the Java/J2EE/Resources perspective. 
> A project configuration will offered and includes
>  - a selection of the configured jBPM runtimes
>  - a checkbox to import all the jBPM Libraries

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 05:39:29 2009
From: jira-events at lists.jboss.org (Tom Baeyens (JIRA))
Date: Thu, 16 Jul 2009 05:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-356) Designer creates
 duplicate handler nodes under decision nodes
In-Reply-To: <2099402771.1247492381837.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <697166806.1247737169511.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Baeyens updated GPD-356:
----------------------------

    Due Date: 07/Aug/09
    Priority: Major  (was: Minor)


> Designer creates duplicate handler nodes under decision nodes
> -------------------------------------------------------------
>
>                 Key: GPD-356
>                 URL: https://jira.jboss.org/jira/browse/GPD-356
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM jPDL Designer 4.0.0.GA
>            Reporter: Alfie Kirkpatrick
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.1
>
>
> When switching between text mode and graphical mode and saving the process definition a few times a large number of handler elements can build up under each decision node. This doesn't seem to affect the running of the process so is more an inconvenience than anything, but could cause confusion if the handler parameters are modified.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 04:27:29 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 16 Jul 2009 04:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-89) The implementation
 of isInheritable() in CtNewClass is wrong.
Message-ID: <32388671.1247732849414.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

The implementation of isInheritable() in CtNewClass is wrong.
-------------------------------------------------------------

                 Key: JASSIST-89
                 URL: https://jira.jboss.org/jira/browse/JASSIST-89
             Project: Javassist
          Issue Type: Bug
    Affects Versions: 3.11.0.GA
            Reporter: Shigeru Chiba
            Assignee: Shigeru Chiba
             Fix For: 3.12.0.GA


In CtNewClass,

private boolean isInheritable(int mod, CtClass superclazz) {
        if (Modifier.isPrivate(mod))
            return false;

        if (Modifier.isPackage(mod)) {
            String pname = getPackageName();
            String pname2 = superclazz.getPackageName();
            if (pname == null)
                return pname2 == null;
            else
                pname.equals(pname2);        // <==== should return pname.equals(pname2)
        }

        return true;
    }

Originally reported by Michihiro Horie


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 04:35:41 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 16 Jul 2009 04:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-89) The implementation
 of isInheritable() in CtNewClass is wrong.
In-Reply-To: <32388671.1247732849414.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1075076395.1247733341983.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba resolved JASSIST-89.
----------------------------------

    Resolution: Done


> The implementation of isInheritable() in CtNewClass is wrong.
> -------------------------------------------------------------
>
>                 Key: JASSIST-89
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-89
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.11.0.GA
>            Reporter: Shigeru Chiba
>            Assignee: Shigeru Chiba
>             Fix For: 3.12.0.GA
>
>
> In CtNewClass,
> private boolean isInheritable(int mod, CtClass superclazz) {
>         if (Modifier.isPrivate(mod))
>             return false;
>         if (Modifier.isPackage(mod)) {
>             String pname = getPackageName();
>             String pname2 = superclazz.getPackageName();
>             if (pname == null)
>                 return pname2 == null;
>             else
>                 pname.equals(pname2);        // <==== should return pname.equals(pname2)
>         }
>         return true;
>     }
> Originally reported by Michihiro Horie

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 04:35:42 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 16 Jul 2009 04:35:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JASSIST-89) The implementation
 of isInheritable() in CtNewClass is wrong.
In-Reply-To: <32388671.1247732849414.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <27105947.1247733342096.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shigeru Chiba closed JASSIST-89.
--------------------------------



> The implementation of isInheritable() in CtNewClass is wrong.
> -------------------------------------------------------------
>
>                 Key: JASSIST-89
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-89
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.11.0.GA
>            Reporter: Shigeru Chiba
>            Assignee: Shigeru Chiba
>             Fix For: 3.12.0.GA
>
>
> In CtNewClass,
> private boolean isInheritable(int mod, CtClass superclazz) {
>         if (Modifier.isPrivate(mod))
>             return false;
>         if (Modifier.isPackage(mod)) {
>             String pname = getPackageName();
>             String pname2 = superclazz.getPackageName();
>             if (pname == null)
>                 return pname2 == null;
>             else
>                 pname.equals(pname2);        // <==== should return pname.equals(pname2)
>         }
>         return true;
>     }
> Originally reported by Michihiro Horie

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 04:17:30 2009
From: jira-events at lists.jboss.org (Martin Burger (JIRA))
Date: Thu, 16 Jul 2009 04:17:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-88) It is not possible
 to instrument class Object because of: [source error] cannot find the super
 class of java.lang.Object
Message-ID: <1295983700.1247732250014.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

It is not possible to instrument class Object because of: [source error] cannot find the super class of java.lang.Object
------------------------------------------------------------------------------------------------------------------------

                 Key: JASSIST-88
                 URL: https://jira.jboss.org/jira/browse/JASSIST-88
             Project: Javassist
          Issue Type: Bug
    Affects Versions: 3.10.0.GA
            Reporter: Martin Burger
            Assignee: Shigeru Chiba


I would like to instrument the constructor in class Object. However, class MemberResolver (part of Javassist's compiler) cannot find its superclass. Of course, there is no superclass.

Exception:

javassist.CannotCompileException: [source error] cannot find the super class of java.lang.Object
	at javassist.CtBehavior.setBody(CtBehavior.java:368)
	at javassist.CtBehavior.setBody(CtBehavior.java:334)
	at javassist.CtConstructor.setBody(CtConstructor.java:216)
	at de.unisb.cs.st.deltadebugging.jinsi.agent.capture.CaptureAgent.premain(CaptureAgent.java:33)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	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 sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:323)
	at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:338)
Caused by: compile error: cannot find the super class of java.lang.Object
	at javassist.compiler.MemberResolver.getSuperclass(MemberResolver.java:490)
	at javassist.compiler.MemberCodeGen.insertDefaultSuperCall(MemberCodeGen.java:80)
	at javassist.compiler.CodeGen.atMethodBody(CodeGen.java:288)
	at javassist.compiler.Javac.compileBody(Javac.java:222)
	at javassist.CtBehavior.setBody(CtBehavior.java:360)
	... 9 more

In javassist.compiler.CodeGen.atMethodBody(Stmnt, boolean, boolean) the call to method javassist.compiler.CodeGen.needsSuperCall(Stmnt) should return false instead of true, I assume. At least this seems to be the location where this bug could be fixed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 04:37:45 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 16 Jul 2009 04:37:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1178330750.1247733465069.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1011:
---------------------------

    Fix Version/s: 2.6.11


> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 04:47:29 2009
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 16 Jul 2009 04:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-141) Servlet Filter
 against XSS and CSRF
Message-ID: <1119010745.1247734049221.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBWEB-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476520#action_12476520 ] 

Dimitris Andreadis commented on JBWEB-141:
------------------------------------------

Marc, maybe you contribute/test such a filter for JBossWeb yourself?

> Servlet Filter against XSS and CSRF
> -----------------------------------
>
>                 Key: JBWEB-141
>                 URL: https://jira.jboss.org/jira/browse/JBWEB-141
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Marc Schoenefeld
>            Assignee: Remy Maucherat
>            Priority: Minor
>
> Cross-Site scripting and cross-site request forgery attacks are common threat to every web application. 
> So a common solution offered by the http server is helpful to raise the default protection level. 
> A servlet filter will help to  
> a) allow/block requests for a set of XSS regex patterns (per default blacklist suspicious parameter patterns, and optionally whitelist valid requests for well-known applications)  
> b) allow/block requests that fulfil the criteria for being a forged request (failing nonce compare), this will need a javascript helper on the client side, to transparently protect existing applications to provide the shared secret in the session . 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 16 01:38:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 16 Jul 2009 01:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <450715898.1247722709495.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1685:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA
                       (was: 1.4.3.GA)


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 23:40:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 23:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1631) Messages are
 piling up in the queues in clustered environment and not pulled by message
 sucker
In-Reply-To: <30545717.1242929996483.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1692926756.1247715629782.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1631:
------------------------------------

    Attachment: 1631-test-source.zip


> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1631
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP08
>         Environment: Cluster of a few JBoss 4.2.3 servers with JBM 1.4.2.GA-SP1 or 1.4.0.SP3_CP08 running on x64 windows servers.
> JBoss Remoting 2.5.1 or 2.2.3
> Clustered XA connection factory, clustered queues, both server and client (MDBs) are deployed as one application - identical deployment for all servers in a cluster
>            Reporter: Victor Starenky
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 1631-test-source.zip, logs-and-config-prod.zip, logs-and-config-test.zip, TestRecommendationSentProcessorMDB.java
>
>
> We have an EJB3 application is running on a cluster of 7 servers. 
> All servers have the same application farmed across them. 
> We have a clustered queue and using clustered connection factory.
> Originally we ran into the bug JBMESSAGING-1456 and while testing the fix ran into a different problem. After the cluster was running for some time (usually overnight with lots of heavy background processing hapenning at that time) we see messages are "piling up" in some queues on some nodes.
> Sympthoms are:
> MessageCount is not zero (rather in the order of hundreeds), DeliveringCount is zero. These nodes have ConsumerCount=0 for the queues experiencing the problem. Message sucker is configured as far as I can tell. Looks like the problem might be related to client and/or server failover leaving some nodes without consumers while sucker not doing it's job (if I understand it correctly). 
> Once we bump the timeout values much higher than they are in the original config files the problem seems to disappear or at least show up much less frequently. Specifically I'm talking about these values:
> messaging-service.xml:
>       <attribute name="FailoverStartTimeout">180000</attribute>
> remoting-bisocket-service.xml:
>                <attribute name="clientLeasePeriod" isParam="true">30000</attribute>
>                <attribute name="validatorPingPeriod" isParam="true">30000</attribute>
>                <attribute name="validatorPingTimeout" isParam="true">20000</attribute>
>                <attribute name="registerCallbackListener">false</attribute>
>                <attribute name="timeout" isParam="true">240000</attribute>
> While this serves as a temporary workaround we don't feel we can rely on JBM in a production clustered environment without having failover working properly.
> This is a big showstopper for us at the moment.
> Attached are the log files from the prod environment of 7 servers with the config files as well as log files from the test environment with just 2 servers (having same issue) and corresponding configs. The logs were produced by the test version of the messaging code with added logging as per JBMESSAGING-1456.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 15 23:40:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 15 Jul 2009 23:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1631) Messages
 are piling up in the queues in clustered environment and not pulled by
 message sucker
In-Reply-To: <30545717.1242929996483.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1982744325.1247715629589.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476495#action_12476495 ] 

Howard Gao commented on JBMESSAGING-1631:
-----------------------------------------

Hi Hossein,

I still can't reproduce it in my env. I changed the MDB to use Topic and send messaged every 10 minutes, and 2000 messages for each sending. It looks like both MDB got all the messages in the overnight test.

I'm uploading my test source (1631-test-source.zip), can you help me how to get this reproduced? Thanks.

Howard


> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1631
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP08
>         Environment: Cluster of a few JBoss 4.2.3 servers with JBM 1.4.2.GA-SP1 or 1.4.0.SP3_CP08 running on x64 windows servers.
> JBoss Remoting 2.5.1 or 2.2.3
> Clustered XA connection factory, clustered queues, both server and client (MDBs) are deployed as one application - identical deployment for all servers in a cluster
>            Reporter: Victor Starenky
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: 1631-test-source.zip, logs-and-config-prod.zip, logs-and-config-test.zip, TestRecommendationSentProcessorMDB.java
>
>
> We have an EJB3 application is running on a cluster of 7 servers. 
> All servers have the same application farmed across them. 
> We have a clustered queue and using clustered connection factory.
> Originally we ran into the bug JBMESSAGING-1456 and while testing the fix ran into a different problem. After the cluster was running for some time (usually overnight with lots of heavy background processing hapenning at that time) we see messages are "piling up" in some queues on some nodes.
> Sympthoms are:
> MessageCount is not zero (rather in the order of hundreeds), DeliveringCount is zero. These nodes have ConsumerCount=0 for the queues experiencing the problem. Message sucker is configured as far as I can tell. Looks like the problem might be related to client and/or server failover leaving some nodes without consumers while sucker not doing it's job (if I understand it correctly). 
> Once we bump the timeout values much higher than they are in the original config files the problem seems to disappear or at least show up much less frequently. Specifically I'm talking about these values:
> messaging-service.xml:
>       <attribute name="FailoverStartTimeout">180000</attribute>
> remoting-bisocket-service.xml:
>                <attribute name="clientLeasePeriod" isParam="true">30000</attribute>
>                <attribute name="validatorPingPeriod" isParam="true">30000</attribute>
>                <attribute name="validatorPingTimeout" isParam="true">20000</attribute>
>                <attribute name="registerCallbackListener">false</attribute>
>                <attribute name="timeout" isParam="true">240000</attribute>
> While this serves as a temporary workaround we don't feel we can rely on JBM in a production clustered environment without having failover working properly.
> This is a big showstopper for us at the moment.
> Attached are the log files from the prod environment of 7 servers with the config files as well as log files from the test environment with just 2 servers (having same issue) and corresponding configs. The logs were produced by the test version of the messaging code with added logging as per JBMESSAGING-1456.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 18 17:49:41 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Jul 2009 17:49:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-7055)
 testValidateSBMContent having problems with hostnames
In-Reply-To: <3567712.1245871496476.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <613523752.1247953781665.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned JBAS-7055:
--------------------------------------

    Assignee: Brian Stansberry  (was: Scott M Stark)


> testValidateSBMContent having problems with hostnames 
> ------------------------------------------------------
>
>                 Key: JBAS-7055
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7055
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Solaris 9/10 both x86 and sparc
> HPUX both ia64 and risc 
>            Reporter: Richard Achmatowicz
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> See the JBPAPP-2139 issue for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 18 19:04:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Jul 2009 19:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7055)
 testValidateSBMContent having problems with hostnames
In-Reply-To: <3567712.1245871496476.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1333786539.1247958269217.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7055.
----------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1
       Resolution: Done


Just a test problem.

> testValidateSBMContent having problems with hostnames 
> ------------------------------------------------------
>
>                 Key: JBAS-7055
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7055
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Solaris 9/10 both x86 and sparc
> HPUX both ia64 and risc 
>            Reporter: Richard Achmatowicz
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> See the JBPAPP-2139 issue for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 16:50:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 20 Jul 2009 16:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
In-Reply-To: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <488220440.1248123029391.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7108:
-------------------------------

        Fix Version/s: JBossAS-5.2.0.Beta1
    Affects Version/s: JBossAS-5.1.0.GA
                           (was: JBossAS-5.2.0.Beta1)
               Labels: embjopr1_3 managedobjects  (was: )


> Unable to collect EJB3 invocation statistics
> --------------------------------------------
>
>                 Key: JBAS-7108
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:
> java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 16:54:29 2009
From: jira-events at lists.jboss.org (Gurkan Erdogdu (JIRA))
Date: Mon, 20 Jul 2009 16:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-112) Adding Partial
 Implementation for Specification Chapter11
In-Reply-To: <546837010.1247330860697.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <774631584.1248123269263.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gurkan Erdogdu updated JBJCA-112:
---------------------------------

    Attachment: commonProject_last.patch
                coreProject_last.patch
                coreTest_last.patch


Update of the patches. Changes to WorkManagerImpl to remove duplicates and tidy up code. Update WorkWrapper to reflect "WorkContext" setup.

Please review my patch before updating repo.

Thanks;

--Gurkan

> Adding Partial Implementation for Specification Chapter11
> ---------------------------------------------------------
>
>                 Key: JBJCA-112
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-112
>             Project: JBoss JCA
>          Issue Type: Patch
>          Components: Core
>            Reporter: Gurkan Erdogdu
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>         Attachments: CommonProject.diff, CommonProject.patch, commonProject_last.patch, CoreProject.diff, CoreProject.patch, coreProject_last.patch, CoreProjectTest.patch, CoreTest.diff, coreTest_last.patch
>
>
> I have implemented some of checks that are defined in the specification Chapter 11.
> 3 different patches exist
> 1* CommonProject.diff --> Contains utility class.
> 2* CoreProject.diff --> Updating WorkWrapper and WorkManagerImpl to support WorkContextProvider
> 3* CoreTest.diff --> Updating tests for Chapter 11

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 17:18:41 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 17:18:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1872)
 InvocationStats.reset does not clear out methods invoked
Message-ID: <1375204373.1248124721318.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

InvocationStats.reset does not clear out methods invoked
--------------------------------------------------------

                 Key: EJBTHREE-1872
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1872
             Project: EJB 3.0
          Issue Type: Bug
          Components: core
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 1.1.10


Currently the reset operation simply clears the invocation times on each of the methods in the method map.  We should be clearing the map entirely.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 17:22:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 17:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1873) MDB inflow
 invocation does not record InvocationStatistics
Message-ID: <77794088.1248124949153.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

MDB inflow invocation does not record InvocationStatistics
----------------------------------------------------------

                 Key: EJBTHREE-1873
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1873
             Project: EJB 3.0
          Issue Type: Bug
          Components: core
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 1.1.10


Wire up the MessageInflow mechanism to record Invocation Statistics

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 17:24:42 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 17:24:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1873) MDB inflow
 invocation does not record InvocationStatistics
In-Reply-To: <77794088.1248124949153.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <39035168.1248125082137.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved EJBTHREE-1873.
-------------------------------------------

    Resolution: Done


> MDB inflow invocation does not record InvocationStatistics
> ----------------------------------------------------------
>
>                 Key: EJBTHREE-1873
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1873
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.10
>
>
> Wire up the MessageInflow mechanism to record Invocation Statistics

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 17:24:42 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 17:24:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1872)
 InvocationStats.reset does not clear out methods invoked
In-Reply-To: <1375204373.1248124721318.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2130405619.1248125082233.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved EJBTHREE-1872.
-------------------------------------------

    Resolution: Done


> InvocationStats.reset does not clear out methods invoked
> --------------------------------------------------------
>
>                 Key: EJBTHREE-1872
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1872
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.10
>
>
> Currently the reset operation simply clears the invocation times on each of the methods in the method map.  We should be clearing the map entirely.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 17:26:29 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 20 Jul 2009 17:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-140) JBoss STS - add a
 ClaimsHandler interface that allows for pluggable claims interpreters
Message-ID: <631663045.1248125189514.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss STS - add a ClaimsHandler interface that allows for pluggable claims interpreters
---------------------------------------------------------------------------------------

                 Key: JBID-140
                 URL: https://jira.jboss.org/jira/browse/JBID-140
             Project: JBoss Identity
          Issue Type: Task
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha3
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: IDFED-1.0.0.alpha4


A WS-Trust request may contain a set of claims that must be included in the issued token. The claims syntax is not specified, so it must be inferred from the Dialect attribute of the Claims element. We must create a ClaimsHandler or ClaimsProvider interface in the STS system to allow for pluggable configuration of claim handlers.

A possible default implementation could handle claims as specified by the Identity Metasystem Interoperability 1.0 (http://docs.oasis-open.org/imi/ns/identity-200810) and use the JBoss IDM API to obtain the necessary information.

The configuration of the ClaimsHandlers would be similar to the TokeProviders and should also allow for the specification of general properties:

<ClaimsHandlers>
   <ClaimsHandler HandlerClass="...." ClaimsDialect="http://....">
       <Property name="prop" value="value"/>
   </ClaimsHandler>
</ClaimsHandler>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 17:26:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 17:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
In-Reply-To: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <432678983.1248125189448.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476918#action_12476918 ] 

Andrew Lee Rubinger commented on JBAS-7108:
-------------------------------------------

Updated the test case to show the errors.  Resolved the linked dependent issues.  Must release EJB3 and integrate into Branch_5_x, then merge into JBPAPP.

> Unable to collect EJB3 invocation statistics
> --------------------------------------------
>
>                 Key: JBAS-7108
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:
> java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 17:33:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 17:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1874) MDBs must expose
 invocation statistics
Message-ID: <1141295772.1248125609236.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

MDBs must expose invocation statistics
--------------------------------------

                 Key: EJBTHREE-1874
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1874
             Project: EJB 3.0
          Issue Type: Bug
          Components: metrics-deployer
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 1.1.10


Refactor such that invocation statistics are included in the EJB3 MDB ManagmentObject view

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 17:35:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 17:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1874) MDBs must
 expose invocation statistics
In-Reply-To: <1141295772.1248125609236.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <462466904.1248125729169.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved EJBTHREE-1874.
-------------------------------------------

    Resolution: Done


> MDBs must expose invocation statistics
> --------------------------------------
>
>                 Key: EJBTHREE-1874
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1874
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: metrics-deployer
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: 1.1.10
>
>
> Refactor such that invocation statistics are included in the EJB3 MDB ManagmentObject view

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 17:39:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 17:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1831) Clean up
	dependency chains
In-Reply-To: <13433231.1242136368008.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1037790424.1248125969316.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated EJBTHREE-1831:
------------------------------------------

    Fix Version/s:     (was: 1.1.10)


> Clean up dependency chains
> --------------------------
>
>                 Key: EJBTHREE-1831
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1831
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: as-int, ejb3
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>
> The true order should be:
> jboss-ejb3 > as-int > AS
> jboss-ejb3 > Plugin
> Whereas now as-int goes into Plugin.  Also endpoint-deployer should be included in as-int and Plugin, and not explicitly declared by AS itself.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 17:39:29 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 20 Jul 2009 17:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-141) JBoss STS - add
 logging to the STS classes
Message-ID: <209311878.1248125969341.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss STS - add logging to the STS classes
------------------------------------------

                 Key: JBID-141
                 URL: https://jira.jboss.org/jira/browse/JBID-141
             Project: JBoss Identity
          Issue Type: Task
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha3
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: IDFED-1.0.0.alpha4


We need to log the important events in the STS classes using the appropriate log levels.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 17:39:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 17:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1875) Align
 dependencies for 1.1.10 release
Message-ID: <448858236.1248125969494.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Align dependencies for 1.1.10 release
-------------------------------------

                 Key: EJBTHREE-1875
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1875
             Project: EJB 3.0
          Issue Type: Task
          Components: as-int, ejb3, metrics-deployer
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: 1.1.10


Tracking issue for updates to the poms of projects in the release chain

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 17:45:29 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 20 Jul 2009 17:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBID-83) Implement token
 encryption (symmetric and public key)
Message-ID: <1905059177.1248126329221.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen deleted JBID-83:
-------------------------------


> Implement token encryption (symmetric and public key)
> -----------------------------------------------------
>
>                 Key: JBID-83
>                 URL: https://jira.jboss.org/jira/browse/JBID-83
>             Project: JBoss Identity
>          Issue Type: Task
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>
> The request handler must encrypt the tokens generated by the security token provider when needed. We may use the XML Sec API to encrypt the returned tokens.
> Need to look for the XML Signature/Encryption utility for this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 17:55:29 2009
From: jira-events at lists.jboss.org (Marcel Kolsteren (JIRA))
Date: Mon, 20 Jul 2009 17:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBID-132) redirect binding
 computes incorrect signatures for SAML responses
In-Reply-To: <1330676091.1247682749094.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1207740718.1248126929234.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcel Kolsteren resolved JBID-132.
-----------------------------------

    Fix Version/s: IDFED-1.0.0.alpha4
       Resolution: Done


Fixed by svn revision 654.

> redirect binding computes incorrect signatures for SAML responses
> -----------------------------------------------------------------
>
>                 Key: JBID-132
>                 URL: https://jira.jboss.org/jira/browse/JBID-132
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Marcel Kolsteren
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>         Attachments: JBID-132.txt
>
>
> When using the HTTP/Redirect binding with signature support, the signatures for SAMLResponse messages are incorrect. This is caused by the computeSignature method in the RedirectBindingSignatureUtil. This method is called for requests as well as for responses, but when it constructs the string that needs to be signed, it always uses "SAMLRequest":
>       sb.append("SAMLRequest=").append(urlEncodedRequest);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 17:57:29 2009
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 20 Jul 2009 17:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7037) JBossAS 5.x fails
 to use EJB's security domain in jboss.xml when the call is from web
 container
In-Reply-To: <2821553.1245299576703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <897103715.1248127049572.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476922#action_12476922 ] 

Stefan Guilhen commented on JBAS-7037:
--------------------------------------

I've been able to reproduce the error and my preliminary investigation shows that calls made by remote clients directly to the EJBs are being secured as expected. However, when a call is made from a Servlet, the EJB security uses the Web App's domain instead of the domain that has been set in jboss.xml. I'll run the server in debug mode and see if I can figure out why this is happening.

> JBossAS 5.x fails to use EJB's security domain in jboss.xml when the call is from web container
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7037
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7037
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>         Environment: Problem found on Windows platform
>            Reporter: Calvin Lin
>            Assignee: Stefan Guilhen
>             Fix For: JBossAS-5.0.2.GA
>
>         Attachments: ConfigFiles-lib.zip, JBAS-jira-authenBug.zip
>
>
> A degredation from JBoss 4.0.x and 4.2.x to JBoss 5.0.1.GA and JBoss 5.1.0.GA.
> We noticed that the JAAS login in EJB container always picks up the Web app's security domain when the client login is originated from a web application client.  The security domain specified in EJB container's jboss.xml is always ignored in this situation.
> The detailed problem description is posted on JBoss forum:
> http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156863

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 18:01:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 18:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1875) Align
 dependencies for 1.1.10 release
In-Reply-To: <448858236.1248125969494.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2020947794.1248127289152.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger reassigned EJBTHREE-1875:
---------------------------------------------

    Assignee: jaikiran pai  (was: Andrew Lee Rubinger)


Sending to Jaikiran to put the nail in the coffin for ejb3-plugin

> Align dependencies for 1.1.10 release
> -------------------------------------
>
>                 Key: EJBTHREE-1875
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1875
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: as-int, ejb3, metrics-deployer
>            Reporter: Andrew Lee Rubinger
>            Assignee: jaikiran pai
>             Fix For: 1.1.10
>
>
> Tracking issue for updates to the poms of projects in the release chain

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 18:06:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 18:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1875) Align
 dependencies for 1.1.10 release
In-Reply-To: <448858236.1248125969494.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2135634806.1248127589312.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved EJBTHREE-1875.
-------------------------------------------

    Resolution: Done


> Align dependencies for 1.1.10 release
> -------------------------------------
>
>                 Key: EJBTHREE-1875
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1875
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: as-int, ejb3, metrics-deployer
>            Reporter: Andrew Lee Rubinger
>            Assignee: jaikiran pai
>             Fix For: 1.1.10
>
>
> Tracking issue for updates to the poms of projects in the release chain

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 18:06:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 20 Jul 2009 18:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-132) redirect binding
 computes incorrect signatures for SAML responses
In-Reply-To: <1330676091.1247682749094.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1085436292.1248127589428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-132:
-------------------------------

    Fix Version/s: IDFED-1.0.0.beta1
                       (was: IDFED-1.0.0.alpha4)


> redirect binding computes incorrect signatures for SAML responses
> -----------------------------------------------------------------
>
>                 Key: JBID-132
>                 URL: https://jira.jboss.org/jira/browse/JBID-132
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Marcel Kolsteren
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>         Attachments: JBID-132.txt
>
>
> When using the HTTP/Redirect binding with signature support, the signatures for SAMLResponse messages are incorrect. This is caused by the computeSignature method in the RedirectBindingSignatureUtil. This method is called for requests as well as for responses, but when it constructs the string that needs to be signed, it always uses "SAMLRequest":
>       sb.append("SAMLRequest=").append(urlEncodedRequest);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 18:10:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 18:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7111) Upgrade AS to EJB3
	1.1.10
Message-ID: <1342595127.1248127829114.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade AS to EJB3 1.1.10
-------------------------

                 Key: JBAS-7111
                 URL: https://jira.jboss.org/jira/browse/JBAS-7111
             Project: JBoss Application Server
          Issue Type: Thirdparty Change
      Security Level: Public (Everyone can see)
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


Component Upgrade

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 18:44:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 18:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7111) Upgrade AS to EJB3
	1.1.10
In-Reply-To: <1342595127.1248127829114.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1579760812.1248129869174.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBAS-7111.
---------------------------------------

    Resolution: Done


> Upgrade AS to EJB3 1.1.10
> -------------------------
>
>                 Key: JBAS-7111
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7111
>             Project: JBoss Application Server
>          Issue Type: Thirdparty Change
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Component Upgrade

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 18:44:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 18:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7112) EJB3 Metrics Test
 Failing in trunk
Message-ID: <1445531349.1248129869264.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

EJB3 Metrics Test Failing in trunk
----------------------------------

                 Key: JBAS-7112
                 URL: https://jira.jboss.org/jira/browse/JBAS-7112
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: JBossAS-6.0.0.Alpha1


Managed Component not getting deployed?

junit.framework.AssertionFailedError: Component not found; no managed object with name "testEjb3xMetrics.jar/TestLoggingMDB" in: []
	at org.jboss.test.profileservice.test.Ejb3MetricsUnitTestCase.getAndTestManagedComponent(Ejb3MetricsUnitTestCase.java:416)
	at org.jboss.test.profileservice.test.Ejb3MetricsUnitTestCase.testMdb(Ejb3MetricsUnitTestCase.java:319)



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 18:46:42 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 18:46:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
In-Reply-To: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1697276799.1248130002572.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBAS-7108.
---------------------------------------

    Resolution: Done


Tests passing in Branch_5_x.  Failing in trunk for unrelated reasons; @see JBAS-7112 for that.

> Unable to collect EJB3 invocation statistics
> --------------------------------------------
>
>                 Key: JBAS-7108
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:
> java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 18:48:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 20 Jul 2009 18:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7108) Unable to collect
 EJB3 invocation statistics
In-Reply-To: <48149148.1247844149200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2118850283.1248130109285.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476926#action_12476926 ] 

Andrew Lee Rubinger commented on JBAS-7108:
-------------------------------------------

If this needs to go to JBPAPP, please get approval and open a JBPAPP issue.

> Unable to collect EJB3 invocation statistics
> --------------------------------------------
>
>                 Key: JBAS-7108
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7108
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Lukas Krejci
>            Assignee: Andrew Lee Rubinger
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When trying to get invocation statistics on an EJB3 session bean, the following exception occurs:
> java.lang.reflect.UndeclaredThrowableException: Failed to get property 'invocationStats' on component 'ejb3-test.jar/HelloWorldBean'.
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:119)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.reflect.Method
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:163)
> 	at org.jboss.ejb3.metrics.deployer.InvocationStatisticMetaMapper.createMetaValue(InvocationStatisticMetaMapper.java:53)
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.get(KernelBusRuntimeComponentDispatcher.java:98)
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.get(DelegatingComponentDispatcherImpl.java:81)
> 	at sun.reflect.GeneratedMethodAccessor444.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> 	at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 	at org.jboss.aop.generatedproxies.AOPProxy$3.get(AOPProxy$3.java)
> 	at org.jboss.profileservice.management.client.ManagedPropertyDelegate.getValue(ManagedPropertyDelegate.java:151)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.getInvocationStats(AbstractEjbBeanComponent.java:116)
> 	at org.rhq.plugins.jbossas5.AbstractEjbBeanComponent.invokeOperation(AbstractEjbBeanComponent.java:94)
> 	at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> This is taken from an uncommited Jopr integration test but the bug seems obvious enough.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 18:52:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 20 Jul 2009 18:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-119) Hibernate Validator
	4.0.0Beta2
In-Reply-To: <1098713284.1247792429189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1101195032.1248130349189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang updated JBJCA-119:
-----------------------------

    Summary: Hibernate Validator 4.0.0Beta2  (was: Hibernate Validator 4.0.0Beta1)


update to beta2, reference:
http://in.relation.to/Bloggers/RoadToFinalBeanValidationPFD2AndItsImplementationHibernateValidator4Beta2

> Hibernate Validator 4.0.0Beta2
> ------------------------------
>
>                 Key: JBJCA-119
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-119
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> for 303 requirement 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 19:06:29 2009
From: jira-events at lists.jboss.org (Alexandre Navarro (JIRA))
Date: Mon, 20 Jul 2009 19:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-362) The textfield name for
 a state/task for does not work correctly (insert mode enabled)
Message-ID: <1818801381.1248131189718.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

The textfield name for a state/task for does not work correctly (insert mode enabled)
-------------------------------------------------------------------------------------

                 Key: GPD-362
                 URL: https://jira.jboss.org/jira/browse/GPD-362
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM jPDL Designer 4.0.0.GA
            Reporter: Alexandre Navarro
            Assignee: Koen Aers
            Priority: Critical


When you type the name of a state or task on the properties view, the textfield is insert mode, so the name will exactly the reverse 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 19:08:42 2009
From: jira-events at lists.jboss.org (Alexandre Navarro (JIRA))
Date: Mon, 20 Jul 2009 19:08:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-363) Name of Decision box
 are not visible on the grahi.
Message-ID: <2001374101.1248131322839.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Name of Decision box are not visible on the grahi.
--------------------------------------------------

                 Key: GPD-363
                 URL: https://jira.jboss.org/jira/browse/GPD-363
             Project: JBoss jBPM GPD
          Issue Type: Bug
    Affects Versions: jBPM jPDL Designer 4.0.0.GA
            Reporter: Alexandre Navarro
            Assignee: Koen Aers
            Priority: Critical


Name of Decision box are not visible on the grahi.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 23:18:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 20 Jul 2009 23:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1689) Pass
 trustStore parameters to remoting layer
In-Reply-To: <369523920.1248073853274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1996232702.1248146309266.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1689:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> Pass trustStore parameters to remoting layer
> --------------------------------------------
>
>                 Key: JBMESSAGING-1689
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1689
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Security
>    Affects Versions: 1.4.0.SP3
>            Reporter: Colin Mondesir
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> The two trustStore parameters:
> org.jboss.remoting.trustStorePassword
> org.jboss.remoting.trustStore
> Are not currently passed by JBM to the remoting layer.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 23:35:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 20 Jul 2009 23:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1690) Bridge does
 not use targetCffName property
In-Reply-To: <846953131.1248096269430.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <519659489.1248147329312.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1690:
------------------------------------

    Fix Version/s: 1.4.0.SP3.CP09
                   1.4.5.GA


> Bridge does not use targetCffName property
> ------------------------------------------
>
>                 Key: JBMESSAGING-1690
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1690
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.2.GA
>         Environment: n/a
>            Reporter: Lukasz Dywicki
>            Assignee: Tim Fox
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: targetCFF.diff
>
>
> Bridge does not use targetCffName property. It always will be overriden by conditions inside setupJMSObjects method. There is no way to set this value over JMX.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 23:37:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Mon, 20 Jul 2009 23:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1690) Bridge does
 not use targetCffName property
In-Reply-To: <846953131.1248096269430.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <564166620.1248147449234.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao reassigned JBMESSAGING-1690:
---------------------------------------

    Assignee: Howard Gao  (was: Tim Fox)


> Bridge does not use targetCffName property
> ------------------------------------------
>
>                 Key: JBMESSAGING-1690
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1690
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.2.GA
>         Environment: n/a
>            Reporter: Lukasz Dywicki
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: targetCFF.diff
>
>
> Bridge does not use targetCffName property. It always will be overriden by conditions inside setupJMSObjects method. There is no way to set this value over JMX.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 23:43:43 2009
From: jira-events at lists.jboss.org (Paul Smith (JIRA))
Date: Mon, 20 Jul 2009 23:43:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2214) Custom Work Items
 that have the same handler only triggers the first handler in the rule flow
Message-ID: <1102695238.1248147823835.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Custom Work Items that have the same handler only triggers the first handler in the rule flow
---------------------------------------------------------------------------------------------

                 Key: JBRULES-2214
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2214
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler (flow)
    Affects Versions: 5.0.1.FINAL
         Environment: Currently running under JDK 1.6 using Drools 5.0.1 Final
            Reporter: Paul Smith
            Assignee: Mark Proctor


I have created a simple rule flow that runs runs in a rule flow group. It then has two work item nodes that are both of the same type and are designed to simulate a parameterised database lookup. These two work items are named differently in the rule flow but have the same handler class. When I start the process, only the first work item is triggered, not the second one. I have attached a zip file with the eclipse workspace files for testing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 20 23:47:29 2009
From: jira-events at lists.jboss.org (Paul Smith (JIRA))
Date: Mon, 20 Jul 2009 23:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2214) Custom Work Items
 that have the same handler only triggers the first handler in the rule flow
In-Reply-To: <1102695238.1248147823835.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <7905251.1248148049186.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Smith updated JBRULES-2214:
--------------------------------

    Attachment: 2214.zip


Eclipse workspace containing test case

> Custom Work Items that have the same handler only triggers the first handler in the rule flow
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2214
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2214
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Currently running under JDK 1.6 using Drools 5.0.1 Final
>            Reporter: Paul Smith
>            Assignee: Mark Proctor
>         Attachments: 2214.zip
>
>
> I have created a simple rule flow that runs runs in a rule flow group. It then has two work item nodes that are both of the same type and are designed to simulate a parameterised database lookup. These two work items are named differently in the rule flow but have the same handler class. When I start the process, only the first work item is triggered, not the second one. I have attached a zip file with the eclipse workspace files for testing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 00:00:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 21 Jul 2009 00:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1690) Bridge does
 not use targetCffName property
In-Reply-To: <846953131.1248096269430.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <202594523.1248148829867.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476943#action_12476943 ] 

Howard Gao commented on JBMESSAGING-1690:
-----------------------------------------

Hi Lukasz,

This issue has been fixed in the latest release (1.4.4.GA). Can you verify it? Thanks.


Howard


> Bridge does not use targetCffName property
> ------------------------------------------
>
>                 Key: JBMESSAGING-1690
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1690
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.2.GA
>         Environment: n/a
>            Reporter: Lukasz Dywicki
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: targetCFF.diff
>
>
> Bridge does not use targetCffName property. It always will be overriden by conditions inside setupJMSObjects method. There is no way to set this value over JMX.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 00:18:29 2009
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 21 Jul 2009 00:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7110)
 ClusterPartition.ThreadGate can block shutdown of AS
In-Reply-To: <1909704028.1248121829865.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <745721289.1248149909278.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro resolved JBAS-7110.
--------------------------------

    Resolution: Done


Adapted new ThreadGate implementation from org.jboss.cache.util.concurrent.ReclosableLatch utilizing an AbstractQueuedSynchronizer.

> ClusterPartition.ThreadGate can block shutdown of AS
> ----------------------------------------------------
>
>                 Key: JBAS-7110
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7110
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The following stack trace appears in a thread dump, after a failure to shutdown the AS within the testsuite:
> Thread: JBoss Shutdown Hook : priority:5, demon:true, threadId:11, threadState:TIMED_WAITING
> - waiting on <0x1d7ada9> (a org.jboss.ha.framework.server.ClusterPartition$ThreadGate)
> java.lang.Object.wait(Native Method)
> org.jboss.ha.framework.server.ClusterPartition$ThreadGate.await(ClusterPartition.java:2381)
> org.jboss.ha.framework.server.ClusterPartition.callAsynchMethodOnCluster(ClusterPartition.java:1325)
> org.jboss.ha.framework.server.DistributedReplicantManagerImpl.remove(DistributedReplicantManagerImpl.java:448)
> org.jboss.profileservice.cluster.repository.DefaultRepositoryClusteringHandler.shutdown(DefaultRepositoryClusteringHandler.java:275)
> org.jboss.system.server.profileservice.repository.clustered.ClusteredDeploymentRepository.unload(ClusteredDeploymentRepository.java:459)
> org.jboss.system.server.profile.repository.AbstractProfile.destroy(AbstractProfile.java:163)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:97)
> org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.invoke(AbstractProfileLifeCycleAction.java:77)
> org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.uninstall(AbstractProfileLifeCycleAction.java:57)
> org.jboss.system.server.profileservice.repository.AbstractProfileAction.uninstall(AbstractProfileAction.java:70)
> org.jboss.system.server.profileservice.repository.AbstractProfileService.uninstall(AbstractProfileService.java:417)
> org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
> org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1665)
> org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1276)
> org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1180)
> org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1235)
> org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1180)
> org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1235)
> org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:828)
> org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> org.jboss.system.server.profileservice.repository.AbstractProfileService.deactivateProfile(AbstractProfileService.java:448)
> org.jboss.system.server.profileservice.ProfileServiceBootstrap.deactivateProfiles(ProfileServiceBootstrap.java:381)
> org.jboss.system.server.profileservice.ProfileServiceBootstrap.shutdown(ProfileServiceBootstrap.java:339)
> org.jboss.bootstrap.AbstractServerImpl.shutdownServer(AbstractServerImpl.java:571)
> org.jboss.bootstrap.AbstractServerImpl$ShutdownHook.run(AbstractServerImpl.java:909)
> The root cause is a bug in ThreadGate.await(long), which does not correctly return if the timeout value is reached while the gate is still closed.
> This same issue was found and fixed in JBC.  See JBCACHE-1173.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 00:38:41 2009
From: jira-events at lists.jboss.org (Paul Smith (JIRA))
Date: Tue, 21 Jul 2009 00:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2214) Custom Work Items
 that have the same handler only triggers the first handler in the rule flow
In-Reply-To: <1102695238.1248147823835.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1498613872.1248151121941.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Smith closed JBRULES-2214.
-------------------------------

    Resolution: Won't Fix


My appologies. This is invalid. I was not telling the WorkItemManager to complete the work item. Closing.

> Custom Work Items that have the same handler only triggers the first handler in the rule flow
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2214
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2214
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Currently running under JDK 1.6 using Drools 5.0.1 Final
>            Reporter: Paul Smith
>            Assignee: Mark Proctor
>         Attachments: 2214.zip
>
>
> I have created a simple rule flow that runs runs in a rule flow group. It then has two work item nodes that are both of the same type and are designed to simulate a parameterised database lookup. These two work items are named differently in the rule flow but have the same handler class. When I start the process, only the first work item is triggered, not the second one. I have attached a zip file with the eclipse workspace files for testing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 02:32:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 21 Jul 2009 02:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2055341109.1248157949241.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476953#action_12476953 ] 

Howard Gao commented on JBMESSAGING-1685:
-----------------------------------------

Hi Martin, 

I created a simple test program where 2000 session.rollback() are performed. It runs without any problem. I'll upload it and can you have a look please?

I tried with JBOSS 5.1.0.GA/jbm 1.4.3 as well as JBoss 4.2.3.GA / jbm 1.4.4.GA

Thanks.
Howard


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 02:34:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 21 Jul 2009 02:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2134544278.1248158069221.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1685:
------------------------------------

    Attachment: QueueExample.java


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 02:52:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Jul 2009 02:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1012) TP: fetch physical
 address associated with logical address more quickly
In-Reply-To: <547183200.1247820389194.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1552585429.1248159149163.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1012.
----------------------------

    Resolution: Done


AgeOutCache is now used to keep a list of logical addresses for which discovery requests were sent. They get kicked out of the cache after 5 secs, so each request for a given logical address is not sent more than once in 5 secs

> TP: fetch physical address associated with logical address more quickly
> -----------------------------------------------------------------------
>
>                 Key: JGRP-1012
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1012
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> Currently, when we send a unicast message and don't have the physical address available, we send a discovery request for the physical address and trash the message.
> Later, when the physical address has been received and added to the transport's cache, the retransmission of the unicast message will succeed.
> In order not to generate too much traffic, we send such a discovery request only every 5 seconds (hard-coded) max. However, this is for *all* addresses. So if we have physical addresses for P, Q and R missing, the total time to send the 3 discovery requests will be 15 sec max ! So we would not be able to send a unicast to R for up to 15 secs !
> This is bad, we should keep track of *which* addresses we've sent out discovery requests for, and have timeouts based on individual addresses, for example in the form of a cache (keys=addrs, values=last time sent).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 06:43:30 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 21 Jul 2009 06:43:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1689) Pass
 trustStore parameters to remoting layer
In-Reply-To: <369523920.1248073853274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1651219180.1248173010023.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12476981#action_12476981 ] 

Howard Gao commented on JBMESSAGING-1689:
-----------------------------------------

To use these two parameters, we need to pass those properties in constructing Client with its constructor Client(locator, config). 
There are two places in JBM code base where remoting client are created. One is JMSRemotingConnection.start(), the other is ClientConnectionFactoryDelegate.createClient(). We can use the following code to pass the parameters in both places:
      
      String trustStoreLoc = System.getProperty("org.jboss.remoting.trustStore");
      if (trustStoreLoc != null)
      {
         configuration.put("org.jboss.remoting.trustStore", trustStoreLoc);
         String trustStorePassword = System.getProperty("org.jboss.remoting.trustStorePassword");
         if (trustStorePassword != null)
         {
            configuration.put("org.jboss.remoting.trustStorePassword", trustStorePassword);
         }
      }


> Pass trustStore parameters to remoting layer
> --------------------------------------------
>
>                 Key: JBMESSAGING-1689
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1689
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Security
>    Affects Versions: 1.4.0.SP3
>            Reporter: Colin Mondesir
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> The two trustStore parameters:
> org.jboss.remoting.trustStorePassword
> org.jboss.remoting.trustStore
> Are not currently passed by JBM to the remoting layer.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 08:12:29 2009
From: jira-events at lists.jboss.org (Alexandre Navarro (JIRA))
Date: Tue, 21 Jul 2009 08:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-364) Differentiate a human
 task from a programmatic task (java,
 sql ... or state) in the editor as you do between a decision and a task
Message-ID: <1334668197.1248178349410.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Differentiate a human task  from a programmatic task (java, sql ... or state) in the editor as you do between a decision and a task
-----------------------------------------------------------------------------------------------------------------------------------

                 Key: GPD-364
                 URL: https://jira.jboss.org/jira/browse/GPD-364
             Project: JBoss jBPM GPD
          Issue Type: Feature Request
    Affects Versions: jBPM jPDL Designer 4.0.0.GA
            Reporter: Alexandre Navarro
            Assignee: Koen Aers


Differentiate a human task  from a programmatic task (java, sql ... or state) in the editor as you do between a decision and a task

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 08:26:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 21 Jul 2009 08:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7113) Wrong address in
	probe.sh
Message-ID: <374438215.1248179189358.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Wrong address in probe.sh
-------------------------

                 Key: JBAS-7113
                 URL: https://jira.jboss.org/jira/browse/JBAS-7113
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


Bela Ban wrote:
> (probe.sh) uses the wrong port 224.0.0.75 instead of 224.0.75.75. This needs to be 
> changed, either by upgrading jgroups.jar or by adding "
> 
> -addr 224.0.75.75 $*"
> 
> to jboss-5.1.0.GA/bin/probe.sh
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 08:41:29 2009
From: jira-events at lists.jboss.org (Martin Gekeler (JIRA))
Date: Tue, 21 Jul 2009 08:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7059) Compatibility issue
 JBoss-5.1.0.GA -> JBoss-5.0.0.GA
In-Reply-To: <6442969.1246020777740.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <650086546.1248180089572.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gekeler resolved JBAS-7059.
----------------------------------

    Fix Version/s: JBossAS-5.1.0.GA
       Resolution: Won't Fix


The JBoss client classes in 5.0.0.GA are incompatible with JBoss client classes in 5.1.0.GA. 
Solution: Update client classes. 

> Compatibility issue JBoss-5.1.0.GA -> JBoss-5.0.0.GA 
> -----------------------------------------------------
>
>                 Key: JBAS-7059
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7059
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: JBoss-5.1.0.GA, Windows, local PC. 
>            Reporter: Martin Gekeler
>             Fix For: JBossAS-5.1.0.GA
>
>
> java.lang.ClassCastException: javax.naming.Reference cannot be cast to com.sdt.pellworm.ejb.Pellworm
> 	at com.sdt.pellworm.test.junit.TestPellwormEJB.testSayHello(TestPellwormEJB.java:29)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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:168)
> 	at junit.framework.TestCase.runBare(TestCase.java:134)
> 	at junit.framework.TestResult$1.protect(TestResult.java:110)
> 	at junit.framework.TestResult.runProtected(TestResult.java:128)
> 	at junit.framework.TestResult.run(TestResult.java:113)
> 	at junit.framework.TestCase.run(TestCase.java:124)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:232)
> 	at junit.framework.TestSuite.run(TestSuite.java:227)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:232)
> 	at junit.framework.TestSuite.run(TestSuite.java:227)
> 	at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:76)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
> 	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)
> When i call the test case below from within eclipse I get this exception with JBoss-5.1.0.GA. 
> I do not get it with JBoss-5.0.0.GA. 
> Here's the code: 
> public class TestPellwormEJB extends TestCase {
> public void testSayHello() {
>       InitialContext  ctx    = null; 
>       Pellworm tsBean = null; 
>       TestUtils.echoLogHello(this.getClass().getSimpleName(), this.getName()); 
>       try {
>          ctx    = new InitialContext(TestUtils.createInitialContext());
>       } catch (NamingException e) {
>          fail(e.getMessage()); 
>       }
>       try {
>          // tsBean = (Pellworm) ctx.lookup("PellwormBean/remote");
>          Object object = ctx.lookup("PellwormBean/remote");
>          tsBean = (Pellworm) object; 
>       } catch (NamingException e) {
>          fail(e.getMessage()); 
>       }
>                   
>       try {
>          assertEquals("Hallo! Ich bin Pellworm. ", tsBean.sayHello());
>       } catch (RemoteException e) {
>          fail(e.getMessage()); 
>       }
>    }
>    
> }  
> I haven't found a compatiblity issue in the release notes about this. 
> Cheers, 
> -M.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 08:43:29 2009
From: jira-events at lists.jboss.org (Martin Gekeler (JIRA))
Date: Tue, 21 Jul 2009 08:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7059) Compatibility issue
 JBoss-5.1.0.GA -> JBoss-5.0.0.GA
In-Reply-To: <6442969.1246020777740.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1158953747.1248180209249.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gekeler closed JBAS-7059.
--------------------------------



> Compatibility issue JBoss-5.1.0.GA -> JBoss-5.0.0.GA 
> -----------------------------------------------------
>
>                 Key: JBAS-7059
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7059
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: JBoss-5.1.0.GA, Windows, local PC. 
>            Reporter: Martin Gekeler
>             Fix For: JBossAS-5.1.0.GA
>
>
> java.lang.ClassCastException: javax.naming.Reference cannot be cast to com.sdt.pellworm.ejb.Pellworm
> 	at com.sdt.pellworm.test.junit.TestPellwormEJB.testSayHello(TestPellwormEJB.java:29)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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:168)
> 	at junit.framework.TestCase.runBare(TestCase.java:134)
> 	at junit.framework.TestResult$1.protect(TestResult.java:110)
> 	at junit.framework.TestResult.runProtected(TestResult.java:128)
> 	at junit.framework.TestResult.run(TestResult.java:113)
> 	at junit.framework.TestCase.run(TestCase.java:124)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:232)
> 	at junit.framework.TestSuite.run(TestSuite.java:227)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:232)
> 	at junit.framework.TestSuite.run(TestSuite.java:227)
> 	at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:76)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
> 	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)
> When i call the test case below from within eclipse I get this exception with JBoss-5.1.0.GA. 
> I do not get it with JBoss-5.0.0.GA. 
> Here's the code: 
> public class TestPellwormEJB extends TestCase {
> public void testSayHello() {
>       InitialContext  ctx    = null; 
>       Pellworm tsBean = null; 
>       TestUtils.echoLogHello(this.getClass().getSimpleName(), this.getName()); 
>       try {
>          ctx    = new InitialContext(TestUtils.createInitialContext());
>       } catch (NamingException e) {
>          fail(e.getMessage()); 
>       }
>       try {
>          // tsBean = (Pellworm) ctx.lookup("PellwormBean/remote");
>          Object object = ctx.lookup("PellwormBean/remote");
>          tsBean = (Pellworm) object; 
>       } catch (NamingException e) {
>          fail(e.getMessage()); 
>       }
>                   
>       try {
>          assertEquals("Hallo! Ich bin Pellworm. ", tsBean.sayHello());
>       } catch (RemoteException e) {
>          fail(e.getMessage()); 
>       }
>    }
>    
> }  
> I haven't found a compatiblity issue in the release notes about this. 
> Cheers, 
> -M.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 09:30:29 2009
From: jira-events at lists.jboss.org (Garry Wright (JIRA))
Date: Tue, 21 Jul 2009 09:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1870) stopDelivery
 on active MDB results in exception (Session not found)
In-Reply-To: <830057413.1248107189559.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1492225769.1248183029901.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477007#action_12477007 ] 

Garry Wright commented on EJBTHREE-1870:
----------------------------------------

Particularly interested in a fix for this as we use stopDelivery extensively in production to stop MDB consumption on other "instances" of the same MDB and or related components in the event of particular  exceptions. 

> stopDelivery on active MDB results in exception (Session not found)
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-1870
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1870
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: ejb3
>    Affects Versions: 1.1.3
>         Environment: Mac OS/X Leopard, JDK 6, JBoss 5.1.0GA
>            Reporter: Philip Dodds
>         Attachments: stopdelivery-mdb.zip
>
>
> If you start an MDB and introduce a messages to it then use the stopDelivery method of the MDB's MBean to stop it consuming messages you get an exception.  Note this problem only occurs if the MDB has a transaction in flight when the stopDelivery is called.
> 2009-05-20 12:30:52,499 ERROR [org.jboss.messaging.util.ExceptionUtil] (WorkManager(2)-44) Connectio
> nEndpoint[fe-oz919yuf-1-mj809yuf-bruz48-x21o4c5] sendTransaction [ur4-b6b39yuf-1-mj809yuf-bruz48-x21
> o4c5]
> javax.jms.IllegalStateException: Cannot find session with id ie-qz919yuf-1-mj809yuf-bruz48-x21o4c5
> 	at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.processTransaction(ServerConnectionEndpoi
> nt.java:835)
> 	at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.
> java:497)
> 	at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$Co
> nnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:101)
> 	at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.inv
> okeTarget(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
> I have attached a slightly doctors version of the EJB3 MDB example code,  it has been changed to introduce a sleep of 5 seconds in the MDB (to keep the transaction active longer) and also introduces a higher volume of messages to give you a chance to get to the JMX console and call stopDelivery.  If you don't get an exception on the first attempt it is worth trying again as the transaction must be in flight for the problem to occur.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 09:39:29 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Tue, 21 Jul 2009 09:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7114) Undeploy-deploy loop
 of directly referenced applications due to hasStructureBeenModified
Message-ID: <1522448733.1248183569203.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Undeploy-deploy loop of directly referenced applications due to hasStructureBeenModified
----------------------------------------------------------------------------------------

                 Key: JBAS-7114
                 URL: https://jira.jboss.org/jira/browse/JBAS-7114
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: VFS
    Affects Versions: JBossAS-5.1.0.GA
         Environment: 14:51:33,954 INFO  [ServerInfo] Java version: 1.6.0_14,Sun Microsystems Inc.
14:51:33,954 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
14:51:33,954 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 14.0-b16,Sun Microsystems Inc.
14:51:33,954 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
14:51:33,955 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Dcom.sun.management.jmxremote -Xms128m -Xmx1536m -XX:MaxPermSize=256m -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 

            Reporter: Juergen none
            Assignee: Ales Justin


in conf/bootstrap/profile.xml, applicationURIs:
<value>file://home/login-service.sar</value>
<value>file://home/app-local.ear</value>

login-service.sar gets undeployed-redeployed every 5000 ms (HDScanner interval)

from debugging:
org.jboss.system.server.profileservice.repository.HotDeploymentRepository.getModifiedDeployments(), calling hasStructureBeenModified()
for file://home/jboss-login-edirectory-service.sar stays true

both files share same root.getPathName() == "" !
org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker.hasRootBeenModified():
1) root := app-local.ear: (app-local.ear).getPathName() == "", cached value for "" is null, put lastModified of (app-local.ear).getLastModified()
2) root := login-service.sar: (login-service.sar).getPathName() == "", cache value for "" is (app-local.ear).getLastModified() (<= (login-service.sar).getLastModified()) -> redeploy login-service.sar + getCache().invalidateCache(root.getPathName()): set "" to null
3) back to 1) -> loop

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 09:39:29 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Tue, 21 Jul 2009 09:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7114) Undeploy-deploy loop
 of directly referenced applications due to hasStructureBeenModified
In-Reply-To: <1522448733.1248183569203.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <775943110.1248183569305.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juergen none updated JBAS-7114:
-------------------------------

    Description: 
in conf/bootstrap/profile.xml, applicationURIs:
<value>file://home/login-service.sar</value>
<value>file://home/app-local.ear</value>

login-service.sar gets undeployed-redeployed every 5000 ms (HDScanner interval)

from debugging:
org.jboss.system.server.profileservice.repository.HotDeploymentRepository.getModifiedDeployments(), calling hasStructureBeenModified()
for file://home/login-service.sar stays true

both files share same root.getPathName() == "" !
org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker.hasRootBeenModified():
1) root := app-local.ear: (app-local.ear).getPathName() == "", cached value for "" is null, put lastModified of (app-local.ear).getLastModified()
2) root := login-service.sar: (login-service.sar).getPathName() == "", cache value for "" is (app-local.ear).getLastModified() (<= (login-service.sar).getLastModified()) -> redeploy login-service.sar + getCache().invalidateCache(root.getPathName()): set "" to null
3) back to 1) -> loop

  was:
in conf/bootstrap/profile.xml, applicationURIs:
<value>file://home/login-service.sar</value>
<value>file://home/app-local.ear</value>

login-service.sar gets undeployed-redeployed every 5000 ms (HDScanner interval)

from debugging:
org.jboss.system.server.profileservice.repository.HotDeploymentRepository.getModifiedDeployments(), calling hasStructureBeenModified()
for file://home/jboss-login-edirectory-service.sar stays true

both files share same root.getPathName() == "" !
org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker.hasRootBeenModified():
1) root := app-local.ear: (app-local.ear).getPathName() == "", cached value for "" is null, put lastModified of (app-local.ear).getLastModified()
2) root := login-service.sar: (login-service.sar).getPathName() == "", cache value for "" is (app-local.ear).getLastModified() (<= (login-service.sar).getLastModified()) -> redeploy login-service.sar + getCache().invalidateCache(root.getPathName()): set "" to null
3) back to 1) -> loop



> Undeploy-deploy loop of directly referenced applications due to hasStructureBeenModified
> ----------------------------------------------------------------------------------------
>
>                 Key: JBAS-7114
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7114
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: VFS
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: 14:51:33,954 INFO  [ServerInfo] Java version: 1.6.0_14,Sun Microsystems Inc.
> 14:51:33,954 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
> 14:51:33,954 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 14.0-b16,Sun Microsystems Inc.
> 14:51:33,954 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 14:51:33,955 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Dcom.sun.management.jmxremote -Xms128m -Xmx1536m -XX:MaxPermSize=256m -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
>            Reporter: Juergen none
>            Assignee: Ales Justin
>
> in conf/bootstrap/profile.xml, applicationURIs:
> <value>file://home/login-service.sar</value>
> <value>file://home/app-local.ear</value>
> login-service.sar gets undeployed-redeployed every 5000 ms (HDScanner interval)
> from debugging:
> org.jboss.system.server.profileservice.repository.HotDeploymentRepository.getModifiedDeployments(), calling hasStructureBeenModified()
> for file://home/login-service.sar stays true
> both files share same root.getPathName() == "" !
> org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker.hasRootBeenModified():
> 1) root := app-local.ear: (app-local.ear).getPathName() == "", cached value for "" is null, put lastModified of (app-local.ear).getLastModified()
> 2) root := login-service.sar: (login-service.sar).getPathName() == "", cache value for "" is (app-local.ear).getLastModified() (<= (login-service.sar).getLastModified()) -> redeploy login-service.sar + getCache().invalidateCache(root.getPathName()): set "" to null
> 3) back to 1) -> loop

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 09:51:29 2009
From: jira-events at lists.jboss.org (Michael Harvey (JIRA))
Date: Tue, 21 Jul 2009 09:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1276) Run
 Performance Tests on Cluster with JBM and JBoss 5 (testing the shared
 transports)
In-Reply-To: <32566632.1208188075391.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1682913147.1248184289456.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Harvey reassigned JBMESSAGING-1276:
-------------------------------------------

    Assignee: Rajesh Rajasekaran  (was: Phillip Thurmond)


I did not see Pavel in the "Assignee" list

> Run Performance Tests on Cluster with JBM and JBoss 5 (testing the shared transports)
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1276
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1276
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: AS Integration
>            Reporter: Clebert Suconic
>            Assignee: Rajesh Rajasekaran
>             Fix For: Unscheduled
>
>
> As requested by Bela, we should run some performance tests using their new Shared Channels on JGroups 2.6.2 (on JBoss 5)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 09:53:29 2009
From: jira-events at lists.jboss.org (Tej jbpm (JIRA))
Date: Tue, 21 Jul 2009 09:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-365) taskInstance.id not
 accessible in jbpm.mail.templates for custom template
Message-ID: <2017380803.1248184409290.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

taskInstance.id not accessible in jbpm.mail.templates for custom template
-------------------------------------------------------------------------

                 Key: GPD-365
                 URL: https://jira.jboss.org/jira/browse/GPD-365
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM jPDL Designer 3.2
         Environment: Windows Vista, Eclipse 3.4.2, JBPM 3.2.1
            Reporter: Tej jbpm
            Assignee: Koen Aers


Hi 

JSF Expresssion {taskInstance.id} works in the "task-assign" and "task-reminder" mail templates. But when i create a custom template {taskInstance.id} does not return anything.

Whatever variables accessible by default templates should be accessible by custom mail templates as well. 

Thanks

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 10:56:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 21 Jul 2009 10:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1689) Pass
 trustStore parameters to remoting layer
In-Reply-To: <369523920.1248073853274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <427670994.1248188189341.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1689.
-----------------------------------

    Resolution: Done


Done. The secure-socket example has changed to use these parameters to show it works.

> Pass trustStore parameters to remoting layer
> --------------------------------------------
>
>                 Key: JBMESSAGING-1689
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1689
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Security
>    Affects Versions: 1.4.0.SP3
>            Reporter: Colin Mondesir
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> The two trustStore parameters:
> org.jboss.remoting.trustStorePassword
> org.jboss.remoting.trustStore
> Are not currently passed by JBM to the remoting layer.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 11:32:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 21 Jul 2009 11:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1496) Complete large
 message copying
In-Reply-To: <22649485.1233606644293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <986915061.1248190349170.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1496.
----------------------------------------

    Resolution: Done


> Complete large message copying
> ------------------------------
>
>                 Key: JBMESSAGING-1496
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1496
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Improve large message copying, by creating link on file system.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 11:37:29 2009
From: jira-events at lists.jboss.org (Martin Malina (JIRA))
Date: Tue, 21 Jul 2009 11:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1859210009.1248190649586.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477026#action_12477026 ] 

Martin Malina commented on JBAS-7049:
-------------------------------------

Is there any way we can fix this issue with a workaround or do we have to wait if a backport fix makes it into OpenJDK6? So far there is no update on the Bugzilla.

> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 11:43:29 2009
From: jira-events at lists.jboss.org (Martin Malina (JIRA))
Date: Tue, 21 Jul 2009 11:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6966) Some tests fail
 with IBM JDK - java.lang.IllegalArgumentException: SSLv2Hello
In-Reply-To: <28786754.1242998527053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1671591278.1248191009220.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477028#action_12477028 ] 

Martin Malina commented on JBAS-6966:
-------------------------------------

Anil, how can we deprecate it? We were trying to do it with the other JIRA [1] but we didn't find a way to do it then.
If we cannot fix this, we will have to document it as a known issue.

[1] JBPAPP-626

> Some tests fail with IBM JDK - java.lang.IllegalArgumentException: SSLv2Hello
> -----------------------------------------------------------------------------
>
>                 Key: JBAS-6966
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6966
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.5
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: SSLv2Hello-error
>
>
> Some tests in the testsuite are failing due to IBM JDK not supporting the SSLv2Hello protocol:
> 15:10:46,727 ERROR [AbstractKernelController] Error installing to Start: name=jboss:service=invoker,socketType=SSLSocketFactory,type=jrmp,wantsClientAuth=true state=Create mode=Manual requiredState=Installed
> java.lang.IllegalArgumentException: SSLv2Hello
> 	at com.ibm.jsse2.mb.a(mb.java:24)
> 	at com.ibm.jsse2.lb.<init>(lb.java:41)
> 	at com.ibm.jsse2.hc.setEnabledProtocols(hc.java:57)
> 	at org.jboss.security.ssl.DomainServerSocketFactory.createServerSocket(DomainServerSocketFactory.java:267)
> 	at org.jboss.security.ssl.DomainServerSocketFactory.createServerSocket(DomainServerSocketFactory.java:226)
> 	at org.jboss.security.ssl.RMISSLServerSocketFactory.createServerSocket(RMISSLServerSocketFactory.java:120)
> 	at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:638)
> 	at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:272)
> 	at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:219)
> 	at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:398)
> ...
> This problem was previously reported as JBPAPP-626 but never fixed. I'm creating a new JIRA since it now affects more testcases.
> These testcases fail:
> org.jboss.test.jrmp.test.CustomSocketsUnitTestCase
> org.jboss.test.jrmp.test.SSLFailuresSocketsUnitTestCase
> org.jboss.test.jrmp.test.SSLSocketsUnitTestCase
> org.jboss.test.pooled.test.SSLSocketsUnitTestCase
> We can still leave it as it is - meaning documenting these failures as known issues with IBM JDK. I just wanted to make sure we know about it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 11:45:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 21 Jul 2009 11:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <567381131.1248191129471.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477029#action_12477029 ] 

Anil Saldhana commented on JBAS-7049:
-------------------------------------

The workaround is to comment out the "java.security.debug" statement in imports/server-config.xml

> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 11:45:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 21 Jul 2009 11:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1409915708.1248191129680.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBAS-7049:
--------------------------------

    Workaround Description: Comment out the "java.security.debug" statement in imports/server-config.xml of testsuite, until the OpenJDK6 bug is fixed.
                Workaround: [Workaround Exists]


> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 11:53:29 2009
From: jira-events at lists.jboss.org (Martin Malina (JIRA))
Date: Tue, 21 Jul 2009 11:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1031842455.1248191609378.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477032#action_12477032 ] 

Martin Malina commented on JBAS-7049:
-------------------------------------

OK, thanks. If I understand it correctly it only affects the level of logging so it shouldn't cause any regressions. Just to make sure I will try to change it and then run the test suite tomorrow. If it's OK, we can go ahead and commit it.

> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 11:56:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 21 Jul 2009 11:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1595756589.1248191789381.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477033#action_12477033 ] 

Anil Saldhana commented on JBAS-7049:
-------------------------------------

Not possible to just change it for the OpenJDK issue?  We want the debug to be on to see if there are issues on other platforms.

> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 11:22:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 11:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-142) SP Post Form
 Authenticator that can handle signatures
Message-ID: <356609847.1248362549083.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SP Post Form Authenticator that can handle signatures
-----------------------------------------------------

                 Key: JBID-142
                 URL: https://jira.jboss.org/jira/browse/JBID-142
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1


Currently we do not have a form authenticator doing POST on the SP end that can handle signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 10:34:44 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Thu, 23 Jul 2009 10:34:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-21) make
 org.jboss.logging.filter.TCLFilter.isMatchingTCL() non-private for
 overriding purposes
Message-ID: <542988471.1248359684786.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

make org.jboss.logging.filter.TCLFilter.isMatchingTCL() non-private for overriding purposes
-------------------------------------------------------------------------------------------

                 Key: JBLOGGING-21
                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-21
             Project: JBoss Logging
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: jboss-logging-log4j
    Affects Versions: 2.1.0.GA-log4j
         Environment: jboss-5.1.0.GA
            Reporter: Juergen none
            Assignee: Dimitris Andreadis
         Attachments: RegExpTCLFilter.java

I wanted to override TCLFilter to implement a RegExpTCLFilter, but because org.jboss.logging.filter.TCLFilter.isMatchingTCL() is declared private I could not subclass TCLFilter and just override that method.

might be nice to change from private to protected

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 10:14:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 23 Jul 2009 10:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-535) Move task
 configuration in server-config.xml into a target
In-Reply-To: <1701874410.1247777909261.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <140682512.1248358469128.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier reassigned JBBUILD-535:
---------------------------------

    Assignee: Paul Gier


> Move task configuration in server-config.xml into a target
> ----------------------------------------------------------
>
>                 Key: JBBUILD-535
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-535
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the task definitions in server-config.xml are not inside a target.  This means that they can't depend on another target to define their path references.  This should be changed so that everything is done inside targets.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 10:34:44 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Thu, 23 Jul 2009 10:34:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBLOGGING-21) make
 org.jboss.logging.filter.TCLFilter.isMatchingTCL() non-private for
 overriding purposes
In-Reply-To: <542988471.1248359684786.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1910849914.1248359684946.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juergen none updated JBLOGGING-21:
----------------------------------

    Attachment: RegExpTCLFilter.java


> make org.jboss.logging.filter.TCLFilter.isMatchingTCL() non-private for overriding purposes
> -------------------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-21
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-21
>             Project: JBoss Logging
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-log4j
>    Affects Versions: 2.1.0.GA-log4j
>         Environment: jboss-5.1.0.GA
>            Reporter: Juergen none
>            Assignee: Dimitris Andreadis
>         Attachments: RegExpTCLFilter.java
>
>
> I wanted to override TCLFilter to implement a RegExpTCLFilter, but because org.jboss.logging.filter.TCLFilter.isMatchingTCL() is declared private I could not subclass TCLFilter and just override that method.
> might be nice to change from private to protected

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 10:18:29 2009
From: jira-events at lists.jboss.org (Martin Malina (JIRA))
Date: Thu, 23 Jul 2009 10:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6936) Testsuite fails
 during tests-profileservice target with IBM JDK 1.6 - AS instance not
 shutdown
In-Reply-To: <368622.1242662765255.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1668018397.1248358709191.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477294#action_12477294 ] 

Martin Malina commented on JBAS-6936:
-------------------------------------

I am still mainly operating with JBoss AS 5.1.0 GA so there the problem was obviously present.
I just saw the profileservice.excludes definition in build.xml and I was just wondering what it was for since I didn't see it used anywhere.
Anyway, with your commit it is taken care of.

> Testsuite fails during tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6936
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6936
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: threadDump.html
>
>
> The AS fails to start for the second time during the tests-profileservice target of the testsuite. This is caused by the first instance not being properly shutdown by the following ant command: <server:stop name="profileservice"/>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 11:36:29 2009
From: jira-events at lists.jboss.org (Sanne Grinovero (JIRA))
Date: Thu, 23 Jul 2009 11:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1876) CNFE on loading
 business interface of succesfully injected MBean in a quartz activated MDB
Message-ID: <461308215.1248363389242.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CNFE on loading business interface of succesfully injected MBean in a quartz activated MDB
------------------------------------------------------------------------------------------

                 Key: EJBTHREE-1876
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1876
             Project: EJB 3.0
          Issue Type: Bug
         Environment: JBoss 5.1.0.GA, JDK Java version: 1.6.0_14,Sun Microsystems Inc., Fedora 11-64bit
            Reporter: Sanne Grinovero


Getting a classnotfound exception when trying to use a reference to a MBean, injected by annotations.
Both MBean and the timer triggered MDB deploy correctly, also injection is working (something? is injected): the value of the reference is not null; as soon
as a method is called on the injected object CNFE happens on the interface being the type of the reference itself.

Please refer to the forum post for more details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 11:40:41 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 23 Jul 2009 11:40:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1876) CNFE on loading
 business interface of succesfully injected MBean in a quartz activated MDB
In-Reply-To: <461308215.1248363389242.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1334232622.1248363641901.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger reassigned EJBTHREE-1876:
---------------------------------------------

    Assignee: Andrew Lee Rubinger


> CNFE on loading business interface of succesfully injected MBean in a quartz activated MDB
> ------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1876
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1876
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: JBoss 5.1.0.GA, JDK Java version: 1.6.0_14,Sun Microsystems Inc., Fedora 11-64bit
>            Reporter: Sanne Grinovero
>            Assignee: Andrew Lee Rubinger
>
> Getting a classnotfound exception when trying to use a reference to a MBean, injected by annotations.
> Both MBean and the timer triggered MDB deploy correctly, also injection is working (something? is injected): the value of the reference is not null; as soon
> as a method is called on the injected object CNFE happens on the interface being the type of the reference itself.
> Please refer to the forum post for more details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 04:22:49 2009
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Thu, 23 Jul 2009 04:22:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-753) Distribute ant
 with the distro
In-Reply-To: <31300965.1169039633086.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <71304275.1248337369554.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Galder Zamarreno closed JBMESSAGING-753.
----------------------------------------

    Resolution: Out of Date


> Distribute ant with the distro
> ------------------------------
>
>                 Key: JBMESSAGING-753
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-753
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Build System
>            Reporter: Galder Zamarreno
>            Assignee: Tim Fox
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> Add to source and make messaging add it to the binary distribution 
> under util directory. That should speed up patching AS for customers 
> and would guarantee that they use the Ant version that we want them to use.
> This is currently implemented in JBC and JGroups and I find it very useful.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 04:30:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Thu, 23 Jul 2009 04:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-753) Distribute
 ant with the distro
In-Reply-To: <31300965.1169039633086.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1676437172.1248337829836.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Fox reopened JBMESSAGING-753:
---------------------------------



Galder- not sure why you closed this.

This _is_ something we want to do for JBM 2.0

> Distribute ant with the distro
> ------------------------------
>
>                 Key: JBMESSAGING-753
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-753
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Build System
>            Reporter: Galder Zamarreno
>            Assignee: Tim Fox
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> Add to source and make messaging add it to the binary distribution 
> under util directory. That should speed up patching AS for customers 
> and would guarantee that they use the Ant version that we want them to use.
> This is currently implemented in JBC and JGroups and I find it very useful.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 04:35:29 2009
From: jira-events at lists.jboss.org (Galder Zamarreno (JIRA))
Date: Thu, 23 Jul 2009 04:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-753) Distribute
 ant with the distro
In-Reply-To: <31300965.1169039633086.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <104741321.1248338129235.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477276#action_12477276 ] 

Galder Zamarreno commented on JBMESSAGING-753:
----------------------------------------------

Hmmm, Jeff Mesnil sent me an email saying:

"Hi Galder,

We're preparing the release of JBoss Messaging and there is this old issue you reported.
Is it still a concern for you? If it is, I'll fix it for JBM 2.0 otherwise, can you close it?

thanks,
jeff

-- 
Jeff Mesnil <jmesnil at redhat.com>
Core Developer (JBoss Messaging)
JBoss by Red Hat"

It's not a concern for me any more, hence I closed it :)

Maybe Jeff should talk to you instead? :)

> Distribute ant with the distro
> ------------------------------
>
>                 Key: JBMESSAGING-753
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-753
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Build System
>            Reporter: Galder Zamarreno
>            Assignee: Tim Fox
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> Add to source and make messaging add it to the binary distribution 
> under util directory. That should speed up patching AS for customers 
> and would guarantee that they use the Ant version that we want them to use.
> This is currently implemented in JBC and JGroups and I find it very useful.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 00:06:29 2009
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Thu, 23 Jul 2009 00:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBSER-116) Support
 deserialization generics objects
In-Reply-To: <2060572682.1248321029368.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1729539596.1248321989161.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBSER-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Takayoshi Kimura resolved JBSER-116.
------------------------------------

    Resolution: Rejected


It's not relevant to generics. The TestObject is missing default constructor.

> Support deserialization generics objects
> ----------------------------------------
>
>                 Key: JBSER-116
>                 URL: https://jira.jboss.org/jira/browse/JBSER-116
>             Project: JBoss Serialization
>          Issue Type: Feature Request
>    Affects Versions: 1.0.3 GA
>            Reporter: Takayoshi Kimura
>            Assignee: Clebert Suconic
>         Attachments: GenericsTestCase.patch
>
>
> Currently it seems JBoss Serialization doesn't support deserialization objects which contain a class using generics.
> org.jboss.serial.exception.SerializationException: Could not create instance of org.jboss.serial.generics.GenericsTestCase$TestObject - org.jboss.serial.generics.GenericsTestCase$TestObject
> 	at org.jboss.serial.classmetamodel.ClassMetaData.newInstance(ClassMetaData.java:354)
> 	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:219)
> 	at org.jboss.serial.objectmetamodel.DefaultObjectDescriptorStrategy.readObject(DefaultObjectDescriptorStrategy.java:160)
> 	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:264)
> 	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescriptionInternal(ObjectDescriptorFactory.java:82)
> 	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:53)
> 	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:725)
> 	at org.jboss.serial.io.JBossObjectInputStream.readObjectOverride(JBossObjectInputStream.java:211)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
> 	at org.jboss.serial.generics.GenericsTestCase.testGenerics(GenericsTestCase.java:56)
> Caused by: java.lang.InstantiationException: org.jboss.serial.generics.GenericsTestCase$TestObject
> 	at java.lang.Class.newInstance0(Class.java:335)
> 	at java.lang.Class.newInstance(Class.java:303)
> 	at org.jboss.serial.classmetamodel.ClassMetaData.newInstance(ClassMetaData.java:346)
> 	... 24 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 23:50:29 2009
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Wed, 22 Jul 2009 23:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSER-116) Support
 deserialization generics objects
In-Reply-To: <2060572682.1248321029368.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <767849946.1248321029545.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBSER-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Takayoshi Kimura updated JBSER-116:
-----------------------------------

    Attachment: GenericsTestCase.patch


> Support deserialization generics objects
> ----------------------------------------
>
>                 Key: JBSER-116
>                 URL: https://jira.jboss.org/jira/browse/JBSER-116
>             Project: JBoss Serialization
>          Issue Type: Feature Request
>    Affects Versions: 1.0.3 GA
>            Reporter: Takayoshi Kimura
>            Assignee: Clebert Suconic
>         Attachments: GenericsTestCase.patch
>
>
> Currently it seems JBoss Serialization doesn't support deserialization objects which contain a class using generics.
> org.jboss.serial.exception.SerializationException: Could not create instance of org.jboss.serial.generics.GenericsTestCase$TestObject - org.jboss.serial.generics.GenericsTestCase$TestObject
> 	at org.jboss.serial.classmetamodel.ClassMetaData.newInstance(ClassMetaData.java:354)
> 	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:219)
> 	at org.jboss.serial.objectmetamodel.DefaultObjectDescriptorStrategy.readObject(DefaultObjectDescriptorStrategy.java:160)
> 	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:264)
> 	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescriptionInternal(ObjectDescriptorFactory.java:82)
> 	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:53)
> 	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:725)
> 	at org.jboss.serial.io.JBossObjectInputStream.readObjectOverride(JBossObjectInputStream.java:211)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
> 	at org.jboss.serial.generics.GenericsTestCase.testGenerics(GenericsTestCase.java:56)
> Caused by: java.lang.InstantiationException: org.jboss.serial.generics.GenericsTestCase$TestObject
> 	at java.lang.Class.newInstance0(Class.java:335)
> 	at java.lang.Class.newInstance(Class.java:303)
> 	at org.jboss.serial.classmetamodel.ClassMetaData.newInstance(ClassMetaData.java:346)
> 	... 24 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 23:41:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 22 Jul 2009 23:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1664) Ordering
 Group is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1586938086.1248320489153.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477267#action_12477267 ] 

Howard Gao commented on JBMESSAGING-1664:
-----------------------------------------

Currently I think I have two options.

Option 1 is based on my current fix. To limit the memory when we fetch all the messages for a queue from DB, we can use Statement.setFetchSize().

Option 2 is that we split the query into two queries. First we query up to fullSize the messages for a Channel (queue), of which we can safely put those messages whose PAGE_ORD are null values into memory queue. Then we remember the number of messages (say n) having been loaded. Second we query all messages that have null PAGE_ORD values and, after dropping the first n messages, update their PAGE_ORD values.

Option 1 is better. Option 2 is not so simple, as the first query may introduce new SQLs that have to use DB specific syntax. Here is the list of SQL for different DBs:

SELECT * FROM T LIMIT 10 OFFSET 20 	MySQL, PostgreSQL (also supports the standard, since version 8.4), SQLite, H2
SELECT * from T WHERE ROWNUM <= 10 	Oracle (also supports the standard, since Oracle8i)
SELECT FIRST 10 * from T 	Ingres
SELECT FIRST 10 * FROM T order by a 	Informix
SELECT SKIP 20 FIRST 10 * FROM T order by c, d 	Informix (row numbers are filtered after order by is evaluated. SKIP clause was introduced in a v10.00.xC4 fixpack)
SELECT * FROM T FETCH FIRST 10 ROWS ONLY 	DB2 (also supports the standard, in Linux, Windows, and Unix since DB2 v8, z/OS support added in v9)
SELECT TOP 10 * FROM T 	MS SQL Server (also supports the standard, since SQL Server 2005), Sybase ASE, MS Access
SELECT TOP 10 START AT 20 * FROM T 	Sybase SQL Anywhere (also supports the standard, since version 9.0.1)
SELECT FIRST 10 SKIP 20 * FROM T 	Interbase, Firebird
SELECT * FROM T ROWS 20 TO 30 	Firebird (since version 2.1)

http://en.wikipedia.org/wiki/Select_(SQL)


> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 23:50:29 2009
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Wed, 22 Jul 2009 23:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSER-116) Support
 deserialization generics objects
Message-ID: <2060572682.1248321029368.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Support deserialization generics objects
----------------------------------------

                 Key: JBSER-116
                 URL: https://jira.jboss.org/jira/browse/JBSER-116
             Project: JBoss Serialization
          Issue Type: Feature Request
    Affects Versions: 1.0.3 GA
            Reporter: Takayoshi Kimura
            Assignee: Clebert Suconic
         Attachments: GenericsTestCase.patch

Currently it seems JBoss Serialization doesn't support deserialization objects which contain a class using generics.

org.jboss.serial.exception.SerializationException: Could not create instance of org.jboss.serial.generics.GenericsTestCase$TestObject - org.jboss.serial.generics.GenericsTestCase$TestObject
	at org.jboss.serial.classmetamodel.ClassMetaData.newInstance(ClassMetaData.java:354)
	at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:219)
	at org.jboss.serial.objectmetamodel.DefaultObjectDescriptorStrategy.readObject(DefaultObjectDescriptorStrategy.java:160)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:264)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescriptionInternal(ObjectDescriptorFactory.java:82)
	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:53)
	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:725)
	at org.jboss.serial.io.JBossObjectInputStream.readObjectOverride(JBossObjectInputStream.java:211)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
	at org.jboss.serial.generics.GenericsTestCase.testGenerics(GenericsTestCase.java:56)
Caused by: java.lang.InstantiationException: org.jboss.serial.generics.GenericsTestCase$TestObject
	at java.lang.Class.newInstance0(Class.java:335)
	at java.lang.Class.newInstance(Class.java:303)
	at org.jboss.serial.classmetamodel.ClassMetaData.newInstance(ClassMetaData.java:346)
	... 24 more


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 23:09:29 2009
From: jira-events at lists.jboss.org (Jimmy Wilson (JIRA))
Date: Wed, 22 Jul 2009 23:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7120) Patch
 commons-logging so that Jasper doesn't use a deployment's logj4.jar when
 compiling a JSP in that deployment
In-Reply-To: <493131229.1248318449413.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1903086860.1248318569363.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jimmy Wilson updated JBAS-7120:
-------------------------------

    Attachment: commons-logging-1.1.0-jboss.diff-ur.patch


> Patch commons-logging so that Jasper doesn't use a deployment's logj4.jar when compiling a JSP in that deployment
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7120
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7120
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-5.0.0.GA, JBossAS-5.0.1.GA, JBossAS-5.1.0.GA
>            Reporter: Jimmy Wilson
>            Assignee: David Lloyd
>         Attachments: commons-logging-1.1.0-jboss.diff-ur.patch
>
>
> If a deployment (e.g. a WAR) packages its own log4j.jar then Jasper will use that log4j.jar when compiling the deployment's JSPs. This can cause unexpected behavior. Jasper should use JBoss' log4j.jar.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 23:07:29 2009
From: jira-events at lists.jboss.org (Jimmy Wilson (JIRA))
Date: Wed, 22 Jul 2009 23:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7120) Patch
 commons-logging so that Jasper doesn't use a deployment's logj4.jar when
 compiling a JSP in that deployment
Message-ID: <493131229.1248318449413.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Patch commons-logging so that Jasper doesn't use a deployment's logj4.jar when compiling a JSP in that deployment
-----------------------------------------------------------------------------------------------------------------

                 Key: JBAS-7120
                 URL: https://jira.jboss.org/jira/browse/JBAS-7120
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Logging
    Affects Versions: JBossAS-5.1.0.GA, JBossAS-5.0.1.GA, JBossAS-5.0.0.GA
            Reporter: Jimmy Wilson
            Assignee: David Lloyd


If a deployment (e.g. a WAR) packages its own log4j.jar then Jasper will use that log4j.jar when compiling the deployment's JSPs. This can cause unexpected behavior. Jasper should use JBoss' log4j.jar.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 22:03:29 2009
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Wed, 22 Jul 2009 22:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1682) duplicate key
 value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <370267132.1248314609373.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Takayoshi Kimura updated JBMESSAGING-1682:
------------------------------------------

    Affects Version/s: 1.4.0.SP3.CP06
                       1.4.0.SP3.CP05
                        1.4.0.SP3.CP04
                       1.4.0.SP3_CP03
                       1.4.0.SP3.CP02


Updated Affects Version/s to CP02-CP08.

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP02, 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 22:01:29 2009
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Wed, 22 Jul 2009 22:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1682) duplicate
 key value violates unique constraint "jbm_msg_pkey" exceptions in a
 clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <879066548.1248314489393.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Takayoshi Kimura reopened JBMESSAGING-1682:
-------------------------------------------



Reopen to update Affects Version/s.

> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 22:03:29 2009
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Wed, 22 Jul 2009 22:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1682) duplicate key
 value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
In-Reply-To: <872587504.1247110349321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2084627038.1248314609586.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Takayoshi Kimura closed JBMESSAGING-1682.
-----------------------------------------

    Resolution: Done


> duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1682
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1682
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP02, 1.4.0.SP3_CP03,  1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Masao Kato
>            Assignee: Howard Gao
>            Priority: Blocker
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. 
> When message ID is generated at the same time, the exception might be generated by the duplicate of ID. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 19:08:29 2009
From: jira-events at lists.jboss.org (Luca Stancapiano (JIRA))
Date: Wed, 22 Jul 2009 19:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPORTAL-2430) drag and drop and
 partial refresh in a region
In-Reply-To: <1129829044.1246720851383.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1113486798.1248304109199.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luca Stancapiano closed JBPORTAL-2430.
--------------------------------------

    Resolution: Done


of course,

committed in:

https://svn.jboss.org/repos/portal/branches/JBoss_Portal_Branch_2_7

and 

https://svn.jboss.org/repos/portal/branches/JBoss_Portal_Branch_2_7_AS5

> drag and drop and partial refresh in a region
> ---------------------------------------------
>
>                 Key: JBPORTAL-2430
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2430
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core, Portal Theme
>    Affects Versions: 2.7.2 Final
>         Environment: JBoss Portal 2.7.2 in JBoss 4.2.3 and JBoss 5.1
>            Reporter: Luca Stancapiano
>             Fix For: 2.8 Final
>
>
> hi... I added new properties inside the region. With this patch we can decide what region can use partial refresh or drag and drop feature. I've seen that this part is managed in the core but we cannot configure le sngle region for theese properties, so we was forced to use those properties in all the page. I added the two new properties in the org.jboss.portal.theme.tag.RegionTagHandler tag class:
>     private String dndEnabled = null;
>     private String partialRefreshEnabled = null;
> 	/**
> 	 * Attribute handler for the drag and drop of this tag
> 	 * <p>
> 	 * This field enables drag and drop on a chosen region
> 	 * </p>
> 	 * 
> 	 * @param dndEnabled
> 	 *            it can be true or false
> 	 */
> 	public void setDndEnabled(String dndEnabled) {
> 		this.dndEnabled = dndEnabled;
> 	}
>     /**
>      * Attribute handler for the partial refresh of this tag
>      * <p>
>      * This field enables partial refresh on a chosen region
>      * </p>
>      * 
>      * @param partialRefreshEnabled
>      *            it can be true or false
>      */
>     public void setPartialRefreshEnabled(String partialRefreshEnabled) {
>         this.partialRefreshEnabled = partialRefreshEnabled;
>     }
> and this part inside the doTag() method:
> 			
> 	    if (dndEnabled != null)
> 		rrc.getProperties().put(DynaRenderOptions.DND_ENABLED,
> 		      dndEnabled);
>             
>             if (partialRefreshEnabled != null)
>                 rrc.getProperties().put(DynaRenderOptions.PARTIAL_REFRESH_ENABLED,
>                       partialRefreshEnabled);
> I also updated tag descriptor portal-layout.tld inside core and theme projects adding the new properties:
> <taglib
>    xmlns="http://java.sun.com/xml/ns/j2ee"
>    xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd"
>    version="2.0">
>    <tlib-version>1.0</tlib-version>
>    <jsp-version>2.0</jsp-version>
>    <short-name></short-name>
>    <uri>http://www.jboss.org/portal</uri>
>    <tag>
>       <name>region</name>
>       <tag-class>org.jboss.portal.theme.tag.RegionTagHandler</tag-class>
>       <body-content>empty</body-content>
>       <attribute>
>          <name>orientation</name>
>       </attribute>
>       <attribute>
>          <name>regionName</name>
>       </attribute>
>       <attribute>
>          <name>regionID</name>
>       </attribute>
> <---------------------------------------
>       <attribute>
>          <name>dndEnabled</name>
>       </attribute>
>       <attribute>
>          <name>partialRefreshEnabled</name>
>       </attribute>
> ------------------------------------------
>    </tag>
> Now, when we want that only some regions uses this properties we can do inside our layout jsp something as:
> <p:region regionName='left' regionID='regionA' dndEnabled='true' partialRefreshEnabled='false'/>
> If we don't specify that two properties, the region will take the properties of the parent node as well as 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 18:20:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Jul 2009 18:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7119) org.jboss.Main
 doesn't "fix" jgroups.bind_addr passed via JAVA_OPTS
Message-ID: <671760334.1248301229382.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

org.jboss.Main doesn't "fix" jgroups.bind_addr passed via JAVA_OPTS
-------------------------------------------------------------------

                 Key: JBAS-7119
                 URL: https://jira.jboss.org/jira/browse/JBAS-7119
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-5.2.0.Beta1


The logic to "fix" a jgroups.bind_addr value of 0.0.0.0 is only kicking in if the value is passed as an argument to org.jboss.Main. If the value is specified as part of JAVA_OPTS, it gets passed directly to java and doesn't get fixed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 17:24:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Jul 2009 17:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7118) Update JGroups to
	2.6.11
In-Reply-To: <1930678592.1248289829128.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <837023707.1248297869606.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7118.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


> Update JGroups to 2.6.11
> ------------------------
>
>                 Key: JBAS-7118
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7118
>             Project: JBoss Application Server
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> Latest bug fix release.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 17:32:29 2009
From: jira-events at lists.jboss.org (Alex Skor (JIRA))
Date: Wed, 22 Jul 2009 17:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7071) use-try-lock
 option in data source configuration files is ignored
In-Reply-To: <329869123.1246546191859.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1387840036.1248298349382.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477237#action_12477237 ] 

Alex Skor commented on JBAS-7071:
---------------------------------

any plans for releasing 5.1.1 anytime soon with this and other fixes?

> use-try-lock option in data source configuration files is ignored
> -----------------------------------------------------------------
>
>                 Key: JBAS-7071
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7071
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows XP Professional V2002, service pack 3
>            Reporter: Mike Conner
>            Assignee: Jesper Pedersen
>            Priority: Minor
>
> (FYI  your "READ THIS BEFORE ENTERING NEW REPORTS" points to a  "You caught us doing a little maintenance..." page, so pardon me if I missed something in procedure. )
> The data source configuration property "use-try-lock" is effectively ignored.
> This is because the value is defined in configuration as a long, but the object that is actually set on  an
> org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory  extends 
>    org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnectionFactory
> This class defines it as taking an int, not a long:
>    public void setUseTryLock(int useTryLock)
> As such, reflection in ManagedConnectionFactoryDeployment.setManagedConnectionFactoryAttribute() does not find the method and simply logs it at a trace level, so the value never gets set.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 16:11:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 22 Jul 2009 16:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-536) Remove testsuite
 dependency on build-common.xml
Message-ID: <1269820757.1248293489189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Remove testsuite dependency on build-common.xml
-----------------------------------------------

                 Key: JBBUILD-536
                 URL: https://jira.jboss.org/jira/browse/JBBUILD-536
             Project: JBoss Build System
          Issue Type: Sub-task
            Reporter: Paul Gier
            Assignee: Paul Gier




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 16:15:30 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 22 Jul 2009 16:15:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-535) Move task
 configuration in server-config.xml into a target
In-Reply-To: <1701874410.1247777909261.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1068466024.1248293730732.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-535:
------------------------------

    Fix Version/s: Maven Build - App Server (Phase 3)


> Move task configuration in server-config.xml into a target
> ----------------------------------------------------------
>
>                 Key: JBBUILD-535
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-535
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the task definitions in server-config.xml are not inside a target.  This means that they can't depend on another target to define their path references.  This should be changed so that everything is done inside targets.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 16:13:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 22 Jul 2009 16:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-536) Remove testsuite
 dependency on build-common.xml
In-Reply-To: <1269820757.1248293489189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <567118861.1248293609117.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-536:
------------------------------

      Component/s: Maven Builds
    Fix Version/s: Maven Build - App Server (Phase 3)
      Description: The testsuite currently depends on buildmagic/build-common.xml.  This dependency should be removed so that buildmagic is no longer needed.


> Remove testsuite dependency on build-common.xml
> -----------------------------------------------
>
>                 Key: JBBUILD-536
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-536
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> The testsuite currently depends on buildmagic/build-common.xml.  This dependency should be removed so that buildmagic is no longer needed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 16:11:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 22 Jul 2009 16:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-419) Remove testsuite
 dependency on modules.ent
In-Reply-To: <20791453.1189779191245.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1629980288.1248293489140.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-419:
------------------------------

        Summary: Remove testsuite dependency on modules.ent  (was: Enable testsuite to run against maven generated artifacts.)
    Description: The testsuite uses modules.ent to build paths related to the module jars.  Instead these paths can be retrieved from the maven ant tasks.  (was: Once maven is able to generate matching artifacts for the ant build, the testsuite will have to be run against the maven generated stuff.  This will probably involve some modifications to the testsuite.)


> Remove testsuite dependency on modules.ent
> ------------------------------------------
>
>                 Key: JBBUILD-419
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-419
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> The testsuite uses modules.ent to build paths related to the module jars.  Instead these paths can be retrieved from the maven ant tasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 16:53:29 2009
From: jira-events at lists.jboss.org (Sean Han (JIRA))
Date: Wed, 22 Jul 2009 16:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2216) Drools call
 failed with CassCastException when the loca cache is turned on
Message-ID: <619212759.1248296009214.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Drools call failed with CassCastException when the loca cache is turned on
--------------------------------------------------------------------------

                 Key: JBRULES-2216
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2216
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.0.0.CR1
            Reporter: Sean Han
            Assignee: Mark Proctor


When the local cache is turned on, Drools call failed with the following exception:

java.lang.ClassCastException: org.drools.reteoo.BetaMemory cannot be cast to org.drools.reteoo.FromNode$FromMemory
	at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:93)
	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:145)
	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:57)
	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:142)
	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:42)
	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:184)
	at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:146)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1066)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1022)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:810)

Steps to reproduce:
   1. Turn on the local cache 
   2. Start the application using Drools
   3. Shut down Drools Guvnor
   4. Wait the poll period for Rule Agent
   5. Run the application with Drools rules
       You will see the exception.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 16:01:30 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Jul 2009 16:01:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7116) Improper handling of
 domain included in jvmRoute
In-Reply-To: <1089406326.1248204929175.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1236347431.1248292890435.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7116.
----------------------------------

    Resolution: Done


Note that some commits for this issue we're inadvertently committed under JBAS-7016.

> Improper handling of domain included in jvmRoute
> ------------------------------------------------
>
>                 Key: JBAS-7116
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7116
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Tomcat) service
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> org.jboss.web.tomcat.service.session.Util doesn't handle a domain.node as the jvmRoute format:
>    public static String getRealId(String sessionId)
>    {
>       int index = sessionId.lastIndexOf(".");  // WRONG!! Use String.indexOf('.', 0);
>       if (index > 0)
>       {
>          return sessionId.substring(0, index);
>       }
>       else
>       {
>          return sessionId;
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 16:07:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 22 Jul 2009 16:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-531) Remove testsuite
 dependency on libraries.ent
In-Reply-To: <6026725.1243637396349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <622647821.1248293249230.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-531:
------------------------------

        Summary: Remove testsuite dependency on libraries.ent  (was: Build testsuite classpaths directly against jars in local maven repository)
    Description: Currently the testsuite uses the jars in thirdparty via the file libraries.ent.  Instead the paths in the testsuite should directly reference jars in the local maven repository directory.  This can be done by building the paths with the maven ant tasks.  (was: Currently the testsuite uses the jars in thirdparty.  Instead the paths in the testsuite should directly reference jars in the local maven repository directory.)


> Remove testsuite dependency on libraries.ent
> --------------------------------------------
>
>                 Key: JBBUILD-531
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-531
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the testsuite uses the jars in thirdparty via the file libraries.ent.  Instead the paths in the testsuite should directly reference jars in the local maven repository directory.  This can be done by building the paths with the maven ant tasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 15:10:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Jul 2009 15:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7118) Update JGroups to
	2.6.11
Message-ID: <1930678592.1248289829128.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Update JGroups to 2.6.11
------------------------

                 Key: JBAS-7118
                 URL: https://jira.jboss.org/jira/browse/JBAS-7118
             Project: JBoss Application Server
          Issue Type: Component Upgrade
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: JBossAS-5.2.0.Beta1


Latest bug fix release.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 12:07:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 23 Jul 2009 12:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1876) CNFE on loading
 business interface of succesfully injected MBean in a quartz activated MDB
In-Reply-To: <461308215.1248363389242.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1975180285.1248365249375.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned EJBTHREE-1876:
--------------------------------------

    Assignee: jaikiran pai  (was: Andrew Lee Rubinger)


> CNFE on loading business interface of succesfully injected MBean in a quartz activated MDB
> ------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1876
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1876
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: JBoss 5.1.0.GA, JDK Java version: 1.6.0_14,Sun Microsystems Inc., Fedora 11-64bit
>            Reporter: Sanne Grinovero
>            Assignee: jaikiran pai
>
> Getting a classnotfound exception when trying to use a reference to a MBean, injected by annotations.
> Both MBean and the timer triggered MDB deploy correctly, also injection is working (something? is injected): the value of the reference is not null; as soon
> as a method is called on the injected object CNFE happens on the interface being the type of the reference itself.
> Please refer to the forum post for more details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 12:07:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 23 Jul 2009 12:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1876) CNFE on
 loading business interface of succesfully injected MBean in a quartz
 activated MDB
In-Reply-To: <461308215.1248363389242.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1125874307.1248365249538.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477304#action_12477304 ] 

jaikiran pai commented on EJBTHREE-1876:
----------------------------------------

Assigning to myself. Incorrectly assigned to ALR earlier.


> CNFE on loading business interface of succesfully injected MBean in a quartz activated MDB
> ------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1876
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1876
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: JBoss 5.1.0.GA, JDK Java version: 1.6.0_14,Sun Microsystems Inc., Fedora 11-64bit
>            Reporter: Sanne Grinovero
>            Assignee: jaikiran pai
>
> Getting a classnotfound exception when trying to use a reference to a MBean, injected by annotations.
> Both MBean and the timer triggered MDB deploy correctly, also injection is working (something? is injected): the value of the reference is not null; as soon
> as a method is called on the injected object CNFE happens on the interface being the type of the reference itself.
> Please refer to the forum post for more details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 12:38:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 22 Jul 2009 12:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1601) JMSBridge
 won't work with LargeMessages and resend
In-Reply-To: <12004607.1239904702467.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1498084585.1248280709621.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1601:
-----------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245368#4245368


> JMSBridge won't work with LargeMessages and resend
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1601
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1601
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> The JMS Bridge is caching a Message, and resending it when a failure occurs.
> On the case of a LargeMessage, the message should be received again instead of cached.
> Actually caching won't work with LargeMessages at all.
> There should be a config on JMSBridge that would complete disable caching, and the message would be received again in case of failure on either side (src or dest address). The user would need then to configure the JMSBridge accordingly to LargeMessages if that feature is being used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 12:19:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Wed, 22 Jul 2009 12:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7107) Invocation
 statistics not collected on JMX based EJB2 managed components
In-Reply-To: <381985128.1247839649313.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1847272553.1248279569653.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukas Krejci resolved JBAS-7107.
--------------------------------

    Resolution: Cannot Reproduce Bug


This seems to be a Jopr issue. Tracked by JOPR-280.

> Invocation statistics not collected on JMX based EJB2 managed components
> ------------------------------------------------------------------------
>
>                 Key: JBAS-7107
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7107
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>
> This was brought to light while investigating JOPR-280.
> During the Jopr AS5 plugin integration tests the metrics collection on EJB2 SFSBs, SLSBs, MDBs and Entity beans is tested.
> For session beans a single remote method is called 10 times on a single bean. The test then checks for CreateCount == 1 and for appropriate method invocation statistics.
> Both the create count and the invocation stats are always 0/empty. Note that this is also true for the MBeans of the session beans themselves when looking at the values in the jmx-console.
> For MDBs the collection statistics fails "most of the time". This might be because the JNDI name of a bean contains @object-id. Once some messages are delivered to the bean the @object-id part of the JNDI name changes from time to time. I suspect that with that change, the stats go as well.
> Entity bean metrics seem to be collected fine.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 11:57:29 2009
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Wed, 22 Jul 2009 11:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6936) Testsuite fails
 during tests-profileservice target with IBM JDK 1.6 - AS instance not
 shutdown
In-Reply-To: <368622.1242662765255.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <212905887.1248278249220.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-6936:
---------------------------------


These tests were excluded in this commit:
http://fisheye.jboss.org/changelog/JBossAS/?cs=91176

and they are not being run in the EAP-CI runs with IBM JDK 6:
http://hudson.qa.jboss.com/hudson/view/EAP-CI/job/JBoss-EAP-5.0.x-Testsuite-ibm16/31/testReport/org.jboss.test.deployers.seam.test/

where are you seeing the tests still being run?

> Testsuite fails during tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6936
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6936
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: threadDump.html
>
>
> The AS fails to start for the second time during the tests-profileservice target of the testsuite. This is caused by the first instance not being properly shutdown by the following ant command: <server:stop name="profileservice"/>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 11:21:29 2009
From: jira-events at lists.jboss.org (Martin Malina (JIRA))
Date: Wed, 22 Jul 2009 11:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6936) Testsuite fails
 during tests-profileservice target with IBM JDK 1.6 - AS instance not
 shutdown
In-Reply-To: <368622.1242662765255.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1419490700.1248276089209.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477192#action_12477192 ] 

Martin Malina commented on JBAS-6936:
-------------------------------------

I can confirm that after removing those 2 test cases (by simply removing the class files in output/classes) the second instance of AS starts up normally  and hence the whole tests-profileservice target runs normally (although there are some failures).
I didn't find out how to exclude the tests in build.xml - there already is a profileservice.excludes and it is excluding these test cases, but they get executed anyway. I'm not sure how it's supposed to work.

> Testsuite fails during tests-profileservice target with IBM JDK 1.6 - AS instance not shutdown
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6936
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6936
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-5.1.0.CR1
>         Environment: IBM JDK 1.6
>            Reporter: Martin Malina
>            Assignee: Shelly McGowan
>         Attachments: threadDump.html
>
>
> The AS fails to start for the second time during the tests-profileservice target of the testsuite. This is caused by the first instance not being properly shutdown by the following ant command: <server:stop name="profileservice"/>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 11:19:29 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Wed, 22 Jul 2009 11:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket write hangs inside a Lock,
 preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1052574282.1248275969322.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477191#action_12477191 ] 

Victor N commented on JGRP-1003:
--------------------------------

Forgot so say - I took stack traces 3 time with some intervals, it's interesting that one of threads (I marked it with ****) is always reading something from network:

"Connection.Sender [server1:40001 - server2:51740],TestCluster,server1:40001" prio=10 tid=0x08da7c00 nid=0x2a0e waiting on condition [0x1926d000..0x1926de40]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x77389808> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358)
*****	at org.jgroups.blocks.TCPConnectionMap$TCPConnection$Sender.run(TCPConnectionMap.java:594)
	at java.lang.Thread.run(Thread.java:619)

Maybe, this thread is blocked in socket read forever? Is SO_TIMEOUT set here?

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>         Attachments: jgroups_s2.txt, stacktrace.txt
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 09:40:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 22 Jul 2009 09:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7117) Classloader isolation
 test fails
 (org.jboss.test.classloader.test.ScopingUnitTestCase.testWarCommonsLoggingLog4jOverrides)
In-Reply-To: <587200004.1248269920988.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1024299303.1248270029169.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBAS-7117.
-----------------------------

    Resolution: Done


> Classloader isolation test fails (org.jboss.test.classloader.test.ScopingUnitTestCase.testWarCommonsLoggingLog4jOverrides)
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7117
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7117
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging, Web (Tomcat) service
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> We do not provide a "real" commons logging anymore.  Thus if an application wants to override logging by completely replacing commons logging plus the underlying framework of their choice (probably log4j) then they have to provide both JARs; therefore, we can no longer filter that package via the tomcat/src/resources/war-deployers-jboss-beans.xml directive.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 09:38:40 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 22 Jul 2009 09:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7117) Classloader
 isolation test fails
 (org.jboss.test.classloader.test.ScopingUnitTestCase.testWarCommonsLoggingLog4jOverrides)
Message-ID: <587200004.1248269920988.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Classloader isolation test fails (org.jboss.test.classloader.test.ScopingUnitTestCase.testWarCommonsLoggingLog4jOverrides)
--------------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-7117
                 URL: https://jira.jboss.org/jira/browse/JBAS-7117
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Logging, Web (Tomcat) service
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: JBossAS-6.0.0.Alpha1


We do not provide a "real" commons logging anymore.  Thus if an application wants to override logging by completely replacing commons logging plus the underlying framework of their choice (probably log4j) then they have to provide both JARs; therefore, we can no longer filter that package via the tomcat/src/resources/war-deployers-jboss-beans.xml directive.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 08:11:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 22 Jul 2009 08:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1506) Remove JMS &
 JDNI dependencies from MessagingXAResourceRecovery bean for JBoss AS 5.0
In-Reply-To: <12930667.1234454924508.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <531813802.1248264689276.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated JBMESSAGING-1506:
-------------------------------------

    Summary: Remove JMS & JDNI dependencies from MessagingXAResourceRecovery bean for JBoss AS 5.0  (was: Create XAResourceRecovery bean for JBoss AS 5.0)


> Remove JMS & JDNI dependencies from MessagingXAResourceRecovery bean for JBoss AS 5.0
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1506
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1506
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> POJO rather than MBean

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 07:25:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Wed, 22 Jul 2009 07:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-120) javax validation-api
	1.0.CR3
Message-ID: <105271748.1248261929139.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

javax validation-api 1.0.CR3
----------------------------

                 Key: JBJCA-120
                 URL: https://jira.jboss.org/jira/browse/JBJCA-120
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 07:27:29 2009
From: jira-events at lists.jboss.org (Tim Fox (JIRA))
Date: Wed, 22 Jul 2009 07:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1506) Create
 XAResourceRecovery bean for JBoss AS 5.0
In-Reply-To: <12930667.1234454924508.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1991457976.1248262049226.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477163#action_12477163 ] 

Tim Fox commented on JBMESSAGING-1506:
--------------------------------------

This bean should not rely on JNDI or use the JMS API for talking to the JBM server

> Create XAResourceRecovery bean for JBoss AS 5.0
> -----------------------------------------------
>
>                 Key: JBMESSAGING-1506
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1506
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> POJO rather than MBean

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 12:24:41 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Thu, 23 Jul 2009 12:24:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-86) support for
 org.jboss.util.StringPropertyReplacer in
 java.beans.PropertyEditor.getValue() implementations
Message-ID: <2136930207.1248366281283.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

support for org.jboss.util.StringPropertyReplacer in java.beans.PropertyEditor.getValue() implementations
---------------------------------------------------------------------------------------------------------

                 Key: JBCOMMON-86
                 URL: https://jira.jboss.org/jira/browse/JBCOMMON-86
             Project: JBoss Common
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: common-core (2.x)
    Affects Versions: 2.2.14.GA
         Environment: jboss 5.1.0.GA
            Reporter: Juergen none


e.g. properties like ${jboss.server.home.url} could be resolved by URLEditor, TextPropertyEditorSupport, ...

configurabe (on/off) ?
escaping? (e.g. \${jboss.server.home.url} for not resolving)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 06:51:29 2009
From: jira-events at lists.jboss.org (Tej jbpm (JIRA))
Date: Wed, 22 Jul 2009 06:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-367) Unable to delete
	process definition
Message-ID: <153388803.1248259889176.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Unable to delete process definition
-----------------------------------

                 Key: GPD-367
                 URL: https://jira.jboss.org/jira/browse/GPD-367
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM jPDL Designer 3.2
         Environment: Windows Vista, Eclipse 3.4.2, JBPM 3.2.1
            Reporter: Tej jbpm
            Assignee: Koen Aers


I am unable to delete process defitions after I set the notify="yes" in the  process definition. I see that there was a JIRA raised on this before and it was fixed in 3.2.2. but though I tried the fix mentioned it is still not working..

JIRA Reference : https://jira.jboss.org/jira/browse/JBPM-1043



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 07:06:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 22 Jul 2009 07:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1506) Create
 XAResourceRecovery bean for JBoss AS 5.0
In-Reply-To: <12930667.1234454924508.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1274293882.1248260789394.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned JBMESSAGING-1506:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> Create XAResourceRecovery bean for JBoss AS 5.0
> -----------------------------------------------
>
>                 Key: JBMESSAGING-1506
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1506
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> POJO rather than MBean

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 06:47:29 2009
From: jira-events at lists.jboss.org (Tej jbpm (JIRA))
Date: Wed, 22 Jul 2009 06:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-366) Process Definition not
 displayed correctly if xml is updated directly
Message-ID: <737619001.1248259649278.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Process Definition not displayed correctly if xml is updated directly
---------------------------------------------------------------------

                 Key: GPD-366
                 URL: https://jira.jboss.org/jira/browse/GPD-366
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM jPDL Designer 3.2
         Environment: Windows Vista, Eclispe 3.4.2 , JBPM 3.2.1
            Reporter: Tej jbpm
            Assignee: Koen Aers


Whenever I edit the processdefinition.xml directly for example ( I add a mail action class)..the original display in the processdefinition goes strange. IT loses all the transitions.

This does not  happen always. But intermittenly. Because of this whenever i change the xml file i save it and cross check it in the display whether everything is fine.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 05:50:29 2009
From: jira-events at lists.jboss.org (Carsten Ziegeler (JIRA))
Date: Wed, 22 Jul 2009 05:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2435)
 ResourceResponse.setContentLength throws UnsupportedOperationException
Message-ID: <1990585224.1248256229337.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

ResourceResponse.setContentLength throws UnsupportedOperationException
----------------------------------------------------------------------

                 Key: JBPORTAL-2435
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2435
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Portlet
    Affects Versions: 2.7.2 Final
            Reporter: Carsten Ziegeler


When calling ResourceResponse.setContentLength in a ResourceServingPortlet an UnsupportedOperationException is thrown

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 05:27:29 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Wed, 22 Jul 2009 05:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <936738787.1248254849704.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------

    Attachment: Test10K.jpg


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java, QueueExampleLong.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 05:27:30 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Wed, 22 Jul 2009 05:27:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <84109847.1248254850361.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------

    Attachment: Test100K.jpg


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java, QueueExampleLong.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 05:25:43 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Wed, 22 Jul 2009 05:25:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <201346735.1248254743501.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------


hi howard,
thanks for your feedback. i ran your example and it's working fine. since our application guys use JMS for handling large PDFs (generated by a scanner application, to be stored in an archive system) i took your example and
made the message size larger. in addition i put a loop around the execution instruction in the main() method => new QueueExampleLong().run(); to get this running in a loop one must also remove the System.exit() instruction in method
reportResultAndExit of class ExampleSupport.

running this code produces the OOM condition after approximately 194 rounds when running with a message size of 10000 bytes. when running with a size of 100000 bytes the OOM condition occurs after 20 rounds. these values multipled by factor
200 (number of sent messages) both calc up to approximately 390-400 MB. it looks like if the messages are being kept in memory, although doing a final commit() on the session and closing the connection.

attached you'll find the modified code QueueExampleLong.java and two images showing the java heap memory chart out of jconsole and the jboss console showing the OOM condition.
if i can help you any further with more testing or whatever, please let me know. thank you very much for your efforts putting into this.
regards martin 

> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java, QueueExampleLong.java
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 05:25:43 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Wed, 22 Jul 2009 05:25:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <658400348.1248254743775.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------

    Attachment: QueueExampleLong.java


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java, QueueExampleLong.java
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 04:54:29 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Wed, 22 Jul 2009 04:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1003) deadlock in
 TP.send - socket write hangs inside a Lock,
 preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1927877703.1248252869764.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477131#action_12477131 ] 

Victor N commented on JGRP-1003:
--------------------------------

Bela, I reproduced the problem again with the same symptoms - please look into the attached jgroups_s2.txt.

> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>         Attachments: jgroups_s2.txt, stacktrace.txt
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 04:54:29 2009
From: jira-events at lists.jboss.org (Victor N (JIRA))
Date: Wed, 22 Jul 2009 04:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1003) deadlock in TP.send
 - socket write hangs inside a Lock, preventing other threads to do TP.send()
In-Reply-To: <32860919.1246010337051.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1603006614.1248252869499.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Victor N updated JGRP-1003:
---------------------------

    Attachment: jgroups_s2.txt


> deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1003
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1003
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>         Environment: Linux (Debian), kernel 2.6.x
>            Reporter: Victor N
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>         Attachments: jgroups_s2.txt, stacktrace.txt
>
>
> I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml).
> Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace.
> 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns  "out_stream_lock in TP class":
> "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040]                                                             
>    java.lang.Thread.State: RUNNABLE                                                                                                                                              
>         at java.net.SocketOutputStream.socketWrite0(Native Method)                                                                                                               
>         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)                                                                                                   
>         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)                                                                                                        
>         at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)                                                                                                
>         at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)                                                                                                     
>         - locked <0x43427300> (a java.io.BufferedOutputStream)                                                                                                                   
>         at java.io.DataOutputStream.flush(DataOutputStream.java:106)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472)                                                                                   
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453)                                                                                    
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436)                                                                                     
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341)                                                                               
>         at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137)                                                                                                   
>         at org.jgroups.protocols.TCP.send(TCP.java:53)                                                                                                                           
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141)                                                                                                  
>         at org.jgroups.protocols.TP.doSend(TP.java:1105)                                                                                                                         
>         at org.jgroups.protocols.TP.send(TP.java:1088)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.down(Discovery.java:363)                                                                                                              
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:169)                                                                                                                    
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333)                                                                                                                  
>         at org.jgroups.protocols.FD.down(FD.java:327)                                                                                                                            
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72)                                                                                                     
>         at org.jgroups.protocols.BARRIER.down(BARRIER.java:96)                                                                                                                   
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530)                                                                                                      
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476)                                                                                                      
>         at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207)                                                                                                      
>         at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218)                                                                                                
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)                                                                                               
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                    
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                              
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)                                                  
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)                                                        
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                   
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                       
>         at java.lang.Thread.run(Thread.java:619)
>    Locked ownable synchronizers:                                                                                                                                                 
>         - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                                                  
>         - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class:
> "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0]
>    java.lang.Thread.State: WAITING (parking)                                                                                                                                     
>         at sun.misc.Unsafe.park(Native Method)                                                                                                                                   
>         - parking to wait for  <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)                                                                             
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)                                                                                                     
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)                                                      
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)                                                              
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)                                                                   
>         at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)                                                                                     
>         at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)                                                                                                 
>         at org.jgroups.protocols.TP.send(TP.java:1082)                                                                                                                           
>         at org.jgroups.protocols.TP.down(TP.java:907)                                                                                                                            
>         at org.jgroups.protocols.Discovery.up(Discovery.java:274)                                                                                                                
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:995)                                                                                                                   
>         at org.jgroups.protocols.TP.access$100(TP.java:52)                                                                                                                       
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451)                                                                                                 
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427)                                                                                                             
>         at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738)                                                              
>         at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34)                                                         
>         at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)                                                                                           
>         at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658)                                                                                          
>         at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061)                                                                                                           
>         at org.jgroups.protocols.TP.receive(TP.java:1038)                                                                                                                        
>         at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180)                                                                                                             
>         at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553)                                                               
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                 
>                                                                                                                                                                                  
>    Locked ownable synchronizers:                                                                                                                                                 
>         - None
> (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace).
> Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 05:06:29 2009
From: jira-events at lists.jboss.org (Martin Malina (JIRA))
Date: Wed, 22 Jul 2009 05:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7049)
 tests-jacc-securitymgr test server fails to start with OpenJDK 6
In-Reply-To: <17450938.1245781616658.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <763649194.1248253589621.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477134#action_12477134 ] 

Martin Malina commented on JBAS-7049:
-------------------------------------

OK, so as a temporary solution I included patching the config file to the corresponding Hudson job - it's now in the queue. Once I have a full run and see that the workaround works for me I will close this issue. The permanent solution will be when issue gets fixed in OpenJDK.

Also, we should document this in the Release Notes as a known issue - I will follow up on this with Rajesh.

> tests-jacc-securitymgr test server fails to start with OpenJDK 6
> ----------------------------------------------------------------
>
>                 Key: JBAS-7049
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7049
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Shelly McGowan
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: boot.log, error.log, output.log
>
>
> This test server runs with security manager and a server.policy file.  The test target boots fine with Sun JDK 6.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 04:03:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Wed, 22 Jul 2009 04:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7097) Stack overflow
 error when establishing secured connection to Profile Service
Message-ID: <1139028683.1248249809474.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukas Krejci resolved JBAS-7097.
--------------------------------

    Resolution: Done


Haven't seen this in a while. Secured connections work flawlessly in EAP5 branch now.

> Stack overflow error when establishing secured connection to Profile Service
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7097
>             Project: JBoss Application Server
>          Issue Type: Bug
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Jopr rev902, AS5 EAP rev91190
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The stack overflow occurs in Jopr AS5 plugin AbstractProfileServiceConnection.init() after the connection has been established.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
>         at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
> Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
>         at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
>         at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
>         ... 12 more                                                                                                                                                                       
> Caused by: java.lang.StackOverflowError                                                                                                                                                   
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
> ....                                                                           
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
>         ... 18 more                                                                                                                                                                       

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 22 02:50:29 2009
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 22 Jul 2009 02:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2430) drag and drop
 and partial refresh in a region
In-Reply-To: <1129829044.1246720851383.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1497566173.1248245429171.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477119#action_12477119 ] 

Thomas Heute commented on JBPORTAL-2430:
----------------------------------------

Sounds good, you could apply it in Branch_2_7

> drag and drop and partial refresh in a region
> ---------------------------------------------
>
>                 Key: JBPORTAL-2430
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2430
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core, Portal Theme
>    Affects Versions: 2.7.2 Final
>         Environment: JBoss Portal 2.7.2 in JBoss 4.2.3 and JBoss 5.1
>            Reporter: Luca Stancapiano
>             Fix For: 2.8 Final
>
>
> hi... I added new properties inside the region. With this patch we can decide what region can use partial refresh or drag and drop feature. I've seen that this part is managed in the core but we cannot configure le sngle region for theese properties, so we was forced to use those properties in all the page. I added the two new properties in the org.jboss.portal.theme.tag.RegionTagHandler tag class:
>     private String dndEnabled = null;
>     private String partialRefreshEnabled = null;
> 	/**
> 	 * Attribute handler for the drag and drop of this tag
> 	 * <p>
> 	 * This field enables drag and drop on a chosen region
> 	 * </p>
> 	 * 
> 	 * @param dndEnabled
> 	 *            it can be true or false
> 	 */
> 	public void setDndEnabled(String dndEnabled) {
> 		this.dndEnabled = dndEnabled;
> 	}
>     /**
>      * Attribute handler for the partial refresh of this tag
>      * <p>
>      * This field enables partial refresh on a chosen region
>      * </p>
>      * 
>      * @param partialRefreshEnabled
>      *            it can be true or false
>      */
>     public void setPartialRefreshEnabled(String partialRefreshEnabled) {
>         this.partialRefreshEnabled = partialRefreshEnabled;
>     }
> and this part inside the doTag() method:
> 			
> 	    if (dndEnabled != null)
> 		rrc.getProperties().put(DynaRenderOptions.DND_ENABLED,
> 		      dndEnabled);
>             
>             if (partialRefreshEnabled != null)
>                 rrc.getProperties().put(DynaRenderOptions.PARTIAL_REFRESH_ENABLED,
>                       partialRefreshEnabled);
> I also updated tag descriptor portal-layout.tld inside core and theme projects adding the new properties:
> <taglib
>    xmlns="http://java.sun.com/xml/ns/j2ee"
>    xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd"
>    version="2.0">
>    <tlib-version>1.0</tlib-version>
>    <jsp-version>2.0</jsp-version>
>    <short-name></short-name>
>    <uri>http://www.jboss.org/portal</uri>
>    <tag>
>       <name>region</name>
>       <tag-class>org.jboss.portal.theme.tag.RegionTagHandler</tag-class>
>       <body-content>empty</body-content>
>       <attribute>
>          <name>orientation</name>
>       </attribute>
>       <attribute>
>          <name>regionName</name>
>       </attribute>
>       <attribute>
>          <name>regionID</name>
>       </attribute>
> <---------------------------------------
>       <attribute>
>          <name>dndEnabled</name>
>       </attribute>
>       <attribute>
>          <name>partialRefreshEnabled</name>
>       </attribute>
> ------------------------------------------
>    </tag>
> Now, when we want that only some regions uses this properties we can do inside our layout jsp something as:
> <p:region regionName='left' regionID='regionA' dndEnabled='true' partialRefreshEnabled='false'/>
> If we don't specify that two properties, the region will take the properties of the parent node as well as 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 23:17:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 21 Jul 2009 23:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-420) JBoss Security
 2.0.3.SP2 Release
In-Reply-To: <14028107.1245268807366.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1646238612.1248232649231.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed SECURITY-420.
----------------------------------

    Resolution: Done


> JBoss Security 2.0.3.SP2 Release
> --------------------------------
>
>                 Key: SECURITY-420
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-420
>             Project: JBoss Security and Identity Management
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX, Security SPI
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.3.SP2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 12:28:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 23 Jul 2009 12:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1876) CNFE on loading
 business interface of succesfully injected MBean in a quartz activated MDB
In-Reply-To: <461308215.1248363389242.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <758486227.1248366509196.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1876:
-----------------------------------

          Component/s: proxy-impl
    Affects Version/s: 1.1.5


> CNFE on loading business interface of succesfully injected MBean in a quartz activated MDB
> ------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1876
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1876
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: proxy-impl
>    Affects Versions: 1.1.5
>         Environment: JBoss 5.1.0.GA, JDK Java version: 1.6.0_14,Sun Microsystems Inc., Fedora 11-64bit
>            Reporter: Sanne Grinovero
>            Assignee: jaikiran pai
>
> Getting a classnotfound exception when trying to use a reference to a MBean, injected by annotations.
> Both MBean and the timer triggered MDB deploy correctly, also injection is working (something? is injected): the value of the reference is not null; as soon
> as a method is called on the injected object CNFE happens on the interface being the type of the reference itself.
> Please refer to the forum post for more details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 22:00:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 21 Jul 2009 22:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-415) ClientLoginModule
 multi-threaded=false should make SecurityContext client side association
In-Reply-To: <12517767.1244524256604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1765701887.1248228029336.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed SECURITY-415.
----------------------------------

    Resolution: Done


When the flag "multi-threaded" is set to false, then vmwide client security ctx association is established.

Remember never to set this flag inside JBoss AS.

> ClientLoginModule multi-threaded=false should make SecurityContext client side association
> ------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-415
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-415
>             Project: JBoss Security and Identity Management
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: JBossSecurity_2.0.3.SP1
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossSecurity_2.0.3.SP2
>
>
> The ClientLoginModule multi-threaded=false option when missing, should set SecurityContextAssociation.setClient()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 19:19:29 2009
From: jira-events at lists.jboss.org (Sean Han (JIRA))
Date: Tue, 21 Jul 2009 19:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2215) RuleAgent gets
 NullPointerException when Drools guvnor server is not available
Message-ID: <1363755612.1248218369244.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

RuleAgent gets NullPointerException when Drools guvnor server is not available
------------------------------------------------------------------------------

                 Key: JBRULES-2215
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2215
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
         Environment: Linux 
            Reporter: Sean Han
            Assignee: Mark Proctor


RuleAgent gets NullPointerException when Drools guvnor server is not available.

Here is the exception: 
RuleAgent(default) EXCEPTION (Tue Jul 21 14:16:23 PDT 2009): Was unable to reach server.. Stack trace should follow.
java.io.IOException: Was unable to reach server.
	at org.drools.agent.URLScanner.hasChanged(URLScanner.java:155)
	at org.drools.agent.URLScanner.getChangeSet(URLScanner.java:119)
	at org.drools.agent.URLScanner.loadPackageChanges(URLScanner.java:96)
	at org.drools.agent.RuleAgent.checkForChanges(RuleAgent.java:410)
	at org.drools.agent.RuleAgent.refreshRuleBase(RuleAgent.java:362)
	at org.drools.agent.RuleAgent.configure(RuleAgent.java:347)
	at org.drools.agent.RuleAgent.init(RuleAgent.java:247)
	at org.drools.agent.RuleAgent.newRuleAgent(RuleAgent.java:187)
	at org.drools.agent.RuleAgent.newRuleAgent(RuleAgent.java:147)
	at org.drools.agent.RuleAgent.newRuleAgent(RuleAgent.java:256)
...
java.lang.NullPointerException
	at org.drools.agent.RuleAgent.refreshRuleBase(RuleAgent.java:363)
	at org.drools.agent.RuleAgent.configure(RuleAgent.java:347)
	at org.drools.agent.RuleAgent.init(RuleAgent.java:247)
	at org.drools.agent.RuleAgent.newRuleAgent(RuleAgent.java:187)
	at org.drools.agent.RuleAgent.newRuleAgent(RuleAgent.java:147)
	at org.drools.agent.RuleAgent.newRuleAgent(RuleAgent.java:256)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 18:55:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 21 Jul 2009 18:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1568)
 JournalStorageManager should not create large message directories in the
 constructor
In-Reply-To: <9568142.1239016462619.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <482001646.1248216929176.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1568.
----------------------------------------

    Resolution: Done


> JournalStorageManager should not create large message directories in the constructor
> ------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1568
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1568
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> In the JournalStorageManager constructor the various directories (bindings, message, large messages etc) are created.
> This is incorrect, the dirs should be checked and created in the start() method, otherwise the following will fail:
> jsm.start()
> jsm.stop();
> delete the directories
> jsm.start(); //fails
> jsm.stop();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 17:40:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 21 Jul 2009 17:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7116) Improper handling of
 domain included in jvmRoute
In-Reply-To: <1089406326.1248204929175.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <242008032.1248212429681.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated JBAS-7116:
-----------------------------------

    Workaround Description: 
Don't include the domain in the server.xml jvmRoute value; just use a distinct node name for each node. The mapping from node name to domain can be specified in the mod_jk or mod_cluster load balancer configuration and doesn't need to be included in the jvmRoute itself.

For configuring the domain with mod_jk, see the "domain" directive on http://tomcat.apache.org/connectors-doc/reference/workers.html.

For mod_cluster, see the "domain" attribute at http://www.jboss.org/mod_cluster/java/properties.html#proxy

                Workaround: [Workaround Exists]


> Improper handling of domain included in jvmRoute
> ------------------------------------------------
>
>                 Key: JBAS-7116
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7116
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Tomcat) service
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> org.jboss.web.tomcat.service.session.Util doesn't handle a domain.node as the jvmRoute format:
>    public static String getRealId(String sessionId)
>    {
>       int index = sessionId.lastIndexOf(".");  // WRONG!! Use String.indexOf('.', 0);
>       if (index > 0)
>       {
>          return sessionId.substring(0, index);
>       }
>       else
>       {
>          return sessionId;
>       }
>    }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 15:35:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 21 Jul 2009 15:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7116) Improper handling of
 domain included in jvmRoute
Message-ID: <1089406326.1248204929175.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Improper handling of domain included in jvmRoute
------------------------------------------------

                 Key: JBAS-7116
                 URL: https://jira.jboss.org/jira/browse/JBAS-7116
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering, Web (Tomcat) service
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


org.jboss.web.tomcat.service.session.Util doesn't handle a domain.node as the jvmRoute format:

   public static String getRealId(String sessionId)
   {
      int index = sessionId.lastIndexOf(".");  // WRONG!! Use String.indexOf('.', 0);
      if (index > 0)
      {
         return sessionId.substring(0, index);
      }
      else
      {
         return sessionId;
      }
   }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 15:27:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Tue, 21 Jul 2009 15:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7097) Stack overflow
 error when establishing secured connection to Profile Service
Message-ID: <985961051.1248204449379.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477059#action_12477059 ] 

Charles Crouch commented on JBAS-7097:
--------------------------------------

Lukas, if you are happy this is fixed please resolve

> Stack overflow error when establishing secured connection to Profile Service
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-7097
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7097
>             Project: JBoss Application Server
>          Issue Type: Bug
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Jopr rev902, AS5 EAP rev91190
>            Reporter: Lukas Krejci
>            Assignee: Scott M Stark
>            Priority: Blocker
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The stack overflow occurs in Jopr AS5 plugin AbstractProfileServiceConnection.init() after the connection has been established.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException                                                                                                                   
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:54)                                                            
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.connect(AbstractProfileServiceConnectionProvider.java:43)                                         
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.connectToProfileService(ApplicationServerComponent.java:309)                                                               
>         at org.rhq.plugins.jbossas5.ApplicationServerComponent.getAvailability(ApplicationServerComponent.java:148)                                                                       
>         at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:526)                                                                         
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)                                                                                                             
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)                                                                                                                       
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)                                                                                            
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)                                                                                                
>         at java.lang.Thread.run(Thread.java:619)                                                                                                                                          
> Caused by: java.lang.reflect.InvocationTargetException                                                                                                                                    
>         at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)                                                                                                                   
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                          
>         at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                               
>         at org.rhq.plugins.jbossas5.connection.JaasAuthenticationInvocationHandler.invoke(JaasAuthenticationInvocationHandler.java:57)                                                    
>         at $Proxy45.loadProfile(Unknown Source)                                                                                                                                           
>         at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnection.init(AbstractProfileServiceConnection.java:52)                                                            
>         ... 12 more                                                                                                                                                                       
> Caused by: java.lang.StackOverflowError                                                                                                                                                   
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getSecurityContext(SecurityActions.java:447)                                                                                        
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:129)                                                                                                     
>         at org.jboss.aspects.security.SecurityActions$2.run(SecurityActions.java:127)                                                                                                     
>         at java.security.AccessController.doPrivileged(Native Method)                                                                                                                     
>         at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:125)                                                                                              
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:49)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
> ....                                                                           
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.profileservice.remoting.PojiMethodInvocation.invokeNext(PojiMethodInvocation.java:153)                                                                               
>         at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211)                                                                                          
>         at org.jboss.remoting.Client.invoke(Client.java:1724)                                                                                                                             
>         at org.jboss.remoting.Client.invoke(Client.java:629)                                                                                                                              
>         at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)                                                                                     
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)                                                                                   
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)                                                                                 
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)                                                                                                 
>         at org.jboss.aop.generatedproxies.AOPProxy$2.loadProfile(AOPProxy$2.java)                                                                                                         
>         ... 18 more                                                                                                                                                                       

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 14:10:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 21 Jul 2009 14:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7115) Upgrade JSF to
	2.0.0-Beta2
In-Reply-To: <331422428.1248196049274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <324165394.1248199829201.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert resolved JBAS-7115.
--------------------------------

    Resolution: Done


> Upgrade JSF to 2.0.0-Beta2
> --------------------------
>
>                 Key: JBAS-7115
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7115
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: JBossAS-6.0.0.Alpha1
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: JBossAS-6.0.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 13:46:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Tue, 21 Jul 2009 13:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7114) Undeploy-deploy
 loop of directly referenced applications due to hasStructureBeenModified
In-Reply-To: <1522448733.1248183569203.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <533546655.1248198389516.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477050#action_12477050 ] 

Ales Justin commented on JBAS-7114:
-----------------------------------

We need to identify deployments somehow, and path name (relative path from root to deployment) was a logical choice.
Perhaps a workaround would be to have filter on the value + have root at file://home/.

But I see I need to re-think this mechanism, as your use case is valid.
Similar use case would be two exactly same named deployments in two different profile folders.
e.g. home/app.jar and deploy/app.jar, where home/ and deploy/ are roots



> Undeploy-deploy loop of directly referenced applications due to hasStructureBeenModified
> ----------------------------------------------------------------------------------------
>
>                 Key: JBAS-7114
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7114
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: VFS
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: 14:51:33,954 INFO  [ServerInfo] Java version: 1.6.0_14,Sun Microsystems Inc.
> 14:51:33,954 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
> 14:51:33,954 INFO  [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 14.0-b16,Sun Microsystems Inc.
> 14:51:33,954 INFO  [ServerInfo] OS-System: Linux 2.6.25.14-69.fc8,amd64
> 14:51:33,955 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.sh -Dcom.sun.management.jmxremote -Xms128m -Xmx1536m -XX:MaxPermSize=256m -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/opt/jboss/jboss-5.1.0.GA/lib/endorsed 
>            Reporter: Juergen none
>            Assignee: Ales Justin
>
> in conf/bootstrap/profile.xml, applicationURIs:
> <value>file://home/login-service.sar</value>
> <value>file://home/app-local.ear</value>
> login-service.sar gets undeployed-redeployed every 5000 ms (HDScanner interval)
> from debugging:
> org.jboss.system.server.profileservice.repository.HotDeploymentRepository.getModifiedDeployments(), calling hasStructureBeenModified()
> for file://home/login-service.sar stays true
> both files share same root.getPathName() == "" !
> org.jboss.deployers.vfs.spi.structure.modified.MetaDataStructureModificationChecker.hasRootBeenModified():
> 1) root := app-local.ear: (app-local.ear).getPathName() == "", cached value for "" is null, put lastModified of (app-local.ear).getLastModified()
> 2) root := login-service.sar: (login-service.sar).getPathName() == "", cache value for "" is (app-local.ear).getLastModified() (<= (login-service.sar).getLastModified()) -> redeploy login-service.sar + getCache().invalidateCache(root.getPathName()): set "" to null
> 3) back to 1) -> loop

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 12:32:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 23 Jul 2009 12:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBLOGGING-21) make
 org.jboss.logging.filter.TCLFilter.isMatchingTCL() non-private for
 overriding purposes
In-Reply-To: <542988471.1248359684786.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1129024408.1248366749201.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned JBLOGGING-21:
------------------------------------

    Assignee: David Lloyd  (was: Dimitris Andreadis)


> make org.jboss.logging.filter.TCLFilter.isMatchingTCL() non-private for overriding purposes
> -------------------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-21
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-21
>             Project: JBoss Logging
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-log4j
>    Affects Versions: 2.1.0.GA-log4j
>         Environment: jboss-5.1.0.GA
>            Reporter: Juergen none
>            Assignee: David Lloyd
>         Attachments: RegExpTCLFilter.java
>
>
> I wanted to override TCLFilter to implement a RegExpTCLFilter, but because org.jboss.logging.filter.TCLFilter.isMatchingTCL() is declared private I could not subclass TCLFilter and just override that method.
> might be nice to change from private to protected

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 13:07:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 21 Jul 2009 13:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7115) Upgrade JSF to
	2.0.0-Beta2
Message-ID: <331422428.1248196049274.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade JSF to 2.0.0-Beta2
--------------------------

                 Key: JBAS-7115
                 URL: https://jira.jboss.org/jira/browse/JBAS-7115
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JSF
    Affects Versions: JBossAS-6.0.0.Alpha1
            Reporter: Stan Silvert
            Assignee: Stan Silvert
             Fix For: JBossAS-6.0.0.Alpha1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 12:54:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 21 Jul 2009 12:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1568)
 JournalStorageManager should not create large message directories in the
 constructor
In-Reply-To: <9568142.1239016462619.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <245516211.1248195269657.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic reassigned JBMESSAGING-1568:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)


> JournalStorageManager should not create large message directories in the constructor
> ------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1568
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1568
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> In the JournalStorageManager constructor the various directories (bindings, message, large messages etc) are created.
> This is incorrect, the dirs should be checked and created in the start() method, otherwise the following will fail:
> jsm.start()
> jsm.stop();
> delete the directories
> jsm.start(); //fails
> jsm.stop();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 13:00:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 21 Jul 2009 13:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1686) Add more
 transactional options for the JCA adapter
In-Reply-To: <301051903.1247758289359.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1145247752.1248195629223.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1686:
-----------------------------------------

    Assignee: Andy Taylor  (was: Clebert Suconic)


Andy: I' m sending you this JIRA, as you told me you would be implementing as part of your current changes on the JCA.

> Add more transactional options for the JCA adapter
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1686
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1686
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>
> It should be possible to configure transactions for MDBs in a better fashion. Like receiving messages non-transactionally, or batching a number of transactions, even if this would mean non-compliant but activated by the user's choice.
> We already have:
> - Local Transaction
> - XA Transaction
> The options I'm thinking:
> We should add:
> - Batching transactions (commit on every X records... like most users do when processing a high number of messages outside the application server)
> - NonTransactional (messages being received non transactionally.. what should be good for Non Persistent Messages)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 12:58:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 21 Jul 2009 12:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1677) Ping faliures
 under heavy load
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <919065704.1248195509632.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1677:
-----------------------------------------

    Summary: Ping faliures under heavy load  (was: "Connection failure has been detected" message)


> Ping faliures under heavy load
> ------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>         Attachments: JmsTest-v2.zip, JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 12:56:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 21 Jul 2009 12:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1677) "Connection
 failure has been detected" message
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <6701348.1248195389308.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1677:
-----------------------------------------

    Assignee: Andy Taylor  (was: Clebert Suconic)


> "Connection failure has been detected" message
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>         Attachments: JmsTest-v2.zip, JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 12:58:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Tue, 21 Jul 2009 12:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1677) Ping faliures
 under heavy load
In-Reply-To: <1645968396.1246902051664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1105492398.1248195509927.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1677.
----------------------------------------

    Resolution: Done


> Ping faliures under heavy load
> ------------------------------
>
>                 Key: JBMESSAGING-1677
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1677
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta3
>         Environment: Windows XP SP2
>            Reporter: Naresh Bhatia
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>         Attachments: JmsTest-v2.zip, JmsTest.zip
>
>
> I am having trouble receiving messages reliably using JBM 2.0.0.BETA3 deployed in JBoss AS 5. Every once in a while I am getting a "Connection failure has been detected" message and then I start loosing messages.
> Sample program to reproduce the problem is attached. Please see instructions in readme.txt file. I can send 1000 messages as fast as I can and then see if I receive all of them. Few times I have gotten all 1000, but several times I get much less, say about 600. I get the following warnings in between: 
> 22:58:26.968 WARNING [Thread-44 (group:JBM-client-global-threads-27401341)] [org.jboss.messaging.cor
> e.remoting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping fr
> om server:3
> ...
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.rem
> oting.impl.RemotingConnectionImpl] Connection failure has been detected Did not receive ping from cl
> ient. It is likely a client has exited or crashed without closing its connection, or the network bet
> ween the server and client has failed. The connection will now be closed.:3
> 23:02:56.984 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Client connection failed, clearing up resources for session ceb2cc8d-69d
> 8-11de-9025-0016d433fcb5
> 23:02:57.000 WARNING [Thread-3 (group:JBM-scheduled-threads-10153586)] [org.jboss.messaging.core.ser
> ver.impl.ServerSessionImpl] Cleared up resources for session ceb2cc8d-69d8-11de-9025-0016d433fcb5

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 21 12:30:29 2009
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Tue, 21 Jul 2009 12:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-206) Expose remaining
 public methods in MainDeployer via interface
Message-ID: <741498768.1248193829261.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Expose remaining public methods in MainDeployer via interface
-------------------------------------------------------------

                 Key: JBDEPLOY-206
                 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-206
             Project: JBoss Deployers
          Issue Type: Task
          Components: maindeployer
    Affects Versions: JBDEPLOY-2.0.8.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For:  JBDEPLOY-2.2.x


In MainDeployerImpl we have some remaining public methods that lack proper interface.
They expose impl details, which should be used with care or not at all.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 12:36:29 2009
From: jira-events at lists.jboss.org (Sanne Grinovero (JIRA))
Date: Thu, 23 Jul 2009 12:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1876) CNFE on
 loading business interface of succesfully injected MBean in a quartz
 activated MDB
In-Reply-To: <461308215.1248363389242.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <50128562.1248366989170.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477309#action_12477309 ] 

Sanne Grinovero commented on EJBTHREE-1876:
-------------------------------------------

just discovered that from the MDB I get the same error when injecting a @Stateless bean: classnotfound on interface.
So it's not limited to the interaction with MBeans (Services)

> CNFE on loading business interface of succesfully injected MBean in a quartz activated MDB
> ------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1876
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1876
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: proxy-impl
>    Affects Versions: 1.1.5
>         Environment: JBoss 5.1.0.GA, JDK Java version: 1.6.0_14,Sun Microsystems Inc., Fedora 11-64bit
>            Reporter: Sanne Grinovero
>            Assignee: jaikiran pai
>
> Getting a classnotfound exception when trying to use a reference to a MBean, injected by annotations.
> Both MBean and the timer triggered MDB deploy correctly, also injection is working (something? is injected): the value of the reference is not null; as soon
> as a method is called on the injected object CNFE happens on the interface being the type of the reference itself.
> Please refer to the forum post for more details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 13:43:29 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Thu, 23 Jul 2009 13:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-742) Replace JBoss AOP
 ClassPools by JBoss ClassPools
Message-ID: <2063312568.1248371009352.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Replace JBoss AOP ClassPools by JBoss ClassPools
------------------------------------------------

                 Key: JBAOP-742
                 URL: https://jira.jboss.org/jira/browse/JBAOP-742
             Project: JBoss AOP
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone
             Fix For: 2.2.0.GA


The ClassPools that are being adapted for task JBREFLECT-3 should be used by JBoss AOP.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 14:30:29 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Thu, 23 Jul 2009 14:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREFLECT-55) Create a JBoss
 ClassPool project
Message-ID: <936584046.1248373829290.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Create a JBoss ClassPool project
--------------------------------

                 Key: JBREFLECT-55
                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-55
             Project: JBoss Reflection
          Issue Type: Sub-task
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone


This task consists of creating a jboss-classpool project, based on the ClassPools from JBoss AOP project. Such a project cannot have dependencies to JBoss AOP and should have all tests passing ok.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 14:46:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 23 Jul 2009 14:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-538) Remove any
 remaining buildmagic dependencies
Message-ID: <1146645968.1248374789318.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Remove any remaining buildmagic dependencies
--------------------------------------------

                 Key: JBBUILD-538
                 URL: https://jira.jboss.org/jira/browse/JBBUILD-538
             Project: JBoss Build System
          Issue Type: Sub-task
            Reporter: Paul Gier
            Assignee: Paul Gier




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 14:46:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 23 Jul 2009 14:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-537) Use target
 dependencies instead of antcall to avoid duplicate target invocations
In-Reply-To: <1059955584.1248374669143.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <598772069.1248374789258.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-537:
------------------------------

    Description: There are currently a lot of <antcall> in the testsuite.  Each antcall creates a new ant project instance and invokes all the dependencies of the invoked target.  Possibly this could be improved using either standard target dependencies, or using something like <calltarget> from the antcontrib tasks.


> Use target dependencies instead of antcall to avoid duplicate target invocations
> --------------------------------------------------------------------------------
>
>                 Key: JBBUILD-537
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-537
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>
> There are currently a lot of <antcall> in the testsuite.  Each antcall creates a new ant project instance and invokes all the dependencies of the invoked target.  Possibly this could be improved using either standard target dependencies, or using something like <calltarget> from the antcontrib tasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 14:48:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 23 Jul 2009 14:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-538) Remove any
 remaining buildmagic dependencies
In-Reply-To: <1146645968.1248374789318.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1253083681.1248374909187.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-538:
------------------------------

    Fix Version/s: Maven Build - App Server (Phase 3)


> Remove any remaining buildmagic dependencies
> --------------------------------------------
>
>                 Key: JBBUILD-538
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-538
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 14:48:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 23 Jul 2009 14:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-537) Use target
 dependencies instead of antcall to avoid duplicate target invocations
In-Reply-To: <1059955584.1248374669143.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <356905505.1248374909249.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-537:
------------------------------

    Fix Version/s: Maven Build - App Server (Phase 3)


> Use target dependencies instead of antcall to avoid duplicate target invocations
> --------------------------------------------------------------------------------
>
>                 Key: JBBUILD-537
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-537
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> There are currently a lot of <antcall> in the testsuite.  Each antcall creates a new ant project instance and invokes all the dependencies of the invoked target.  Possibly this could be improved using either standard target dependencies, or using something like <calltarget> from the antcontrib tasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 14:52:29 2009
From: jira-events at lists.jboss.org (Justin Waugh (JIRA))
Date: Thu, 23 Jul 2009 14:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2217) Array Index Out
 of Bounds in ClassFieldInspector with certain method signatures
In-Reply-To: <1755584026.1248374549289.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <286572206.1248375149502.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Justin Waugh updated JBRULES-2217:
----------------------------------

    Component/s: drools-core
                     (was: drools-compiler)


> Array Index Out of Bounds in ClassFieldInspector with certain method signatures
> -------------------------------------------------------------------------------
>
>                 Key: JBRULES-2217
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2217
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>         Environment: JBOSS 4.0.5, Windows Server 2003
>            Reporter: Justin Waugh
>            Assignee: Mark Proctor
>
> If a class has a method named setXXX but is not a traditional bean method, (particularly that it does not have a single parameter) an ArrayOutOfBoundsException will be thrown during class processing from ClassFieldInspector.storeGetterSetter (line 261).  This is because in ClassFieldInspector.processClassWithoutByteCode() it does not filter by method name prefix when trying to process get/is methods, but uses the common method ClassFieldInspector.addToMapping() to handle the method.
> an example problem method name would be:
> public void setTimestampFromCurrentTime();

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 15:02:29 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Thu, 23 Jul 2009 15:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREFLECT-55) Create a JBoss
 ClassPool project
In-Reply-To: <936584046.1248373829290.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <669529526.1248375749362.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBREFLECT-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone closed JBREFLECT-55.
-----------------------------------

    Resolution: Done


The project is created at the location https://svn.jboss.org/repos/jbossas/projects/jboss-classpool, also available at http://anonsvn.jboss.org/repos/jbossas/projects/jboss-classpool

> Create a JBoss ClassPool project
> --------------------------------
>
>                 Key: JBREFLECT-55
>                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-55
>             Project: JBoss Reflection
>          Issue Type: Sub-task
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>
> This task consists of creating a jboss-classpool project, based on the ClassPools from JBoss AOP project. Such a project cannot have dependencies to JBoss AOP and should have all tests passing ok.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 15:02:29 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Thu, 23 Jul 2009 15:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBREFLECT-56) Adapt
 jboss-classpool so it works with JBoss AOP/JBoss AS
In-Reply-To: <1606896600.1248374309128.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2072341640.1248375749439.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBREFLECT-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone reassigned JBREFLECT-56:
---------------------------------------

    Assignee: Flavia Rainone


> Adapt jboss-classpool so it works with JBoss AOP/JBoss AS
> ---------------------------------------------------------
>
>                 Key: JBREFLECT-56
>                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-56
>             Project: JBoss Reflection
>          Issue Type: Sub-task
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>
> This task consists of adapting jboss-classpool so it can be used by JBoss AOP over JBoss AS.
> The goals of this task are:
> - to create a proved initial infrastructure for extending the project
> - to validate the class pools of jboss-classpool inside JBoss AS

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 15:04:29 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Thu, 23 Jul 2009 15:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREFLECT-57) Tidy up the
 jboss-classpool project
Message-ID: <1113420399.1248375869315.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Tidy up the jboss-classpool project
-----------------------------------

                 Key: JBREFLECT-57
                 URL: https://jira.jboss.org/jira/browse/JBREFLECT-57
             Project: JBoss Reflection
          Issue Type: Sub-task
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone


This task consists of
- adding documentation
- adding missing tests, if any
- creating an spi
- refactoring (adding classes to appropriate packages, etc)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 15:23:29 2009
From: jira-events at lists.jboss.org (Justin Waugh (JIRA))
Date: Thu, 23 Jul 2009 15:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2217) Array Index Out
 of Bounds in ClassFieldInspector with certain method signatures
In-Reply-To: <1755584026.1248374549289.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1134356116.1248377009160.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Justin Waugh updated JBRULES-2217:
----------------------------------

    Description: 
If a class has a method named setXXX but is not a traditional bean method, (particularly that it does not have a single parameter and returns a value) an ArrayOutOfBoundsException will be thrown during class processing from ClassFieldInspector.storeGetterSetter (line 261).  This is because in ClassFieldInspector.processClassWithoutByteCode() it improperly detects the method as being a getter, because it does not filter by method name prefix when trying to process get/is methods, but uses the common method ClassFieldInspector.addToMapping() to handle the method. 

an example problem method name would be:

public boolean setDefaultValueAndCheckValidity();

Granted, methods like that might not be ideal programming style, but shouldn't break the processor





  was:
If a class has a method named setXXX but is not a traditional bean method, (particularly that it does not have a single parameter) an ArrayOutOfBoundsException will be thrown during class processing from ClassFieldInspector.storeGetterSetter (line 261).  This is because in ClassFieldInspector.processClassWithoutByteCode() it does not filter by method name prefix when trying to process get/is methods, but uses the common method ClassFieldInspector.addToMapping() to handle the method.

an example problem method name would be:

public void setTimestampFromCurrentTime();







> Array Index Out of Bounds in ClassFieldInspector with certain method signatures
> -------------------------------------------------------------------------------
>
>                 Key: JBRULES-2217
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2217
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>         Environment: JBOSS 4.0.5, Windows Server 2003
>            Reporter: Justin Waugh
>            Assignee: Mark Proctor
>
> If a class has a method named setXXX but is not a traditional bean method, (particularly that it does not have a single parameter and returns a value) an ArrayOutOfBoundsException will be thrown during class processing from ClassFieldInspector.storeGetterSetter (line 261).  This is because in ClassFieldInspector.processClassWithoutByteCode() it improperly detects the method as being a getter, because it does not filter by method name prefix when trying to process get/is methods, but uses the common method ClassFieldInspector.addToMapping() to handle the method. 
> an example problem method name would be:
> public boolean setDefaultValueAndCheckValidity();
> Granted, methods like that might not be ideal programming style, but shouldn't break the processor

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 15:31:42 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 15:31:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-131) OpenID Integration
In-Reply-To: <1207990758.1246906371307.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <147444521.1248377502173.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-131.
------------------------------

    Resolution: Done


> OpenID Integration
> ------------------
>
>                 Key: JBID-131
>                 URL: https://jira.jboss.org/jira/browse/JBID-131
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> Integrate Openid4Java which is ASL 2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 15:31:42 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 15:31:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-131) OpenID Integration
In-Reply-To: <1207990758.1246906371307.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <757829509.1248377502102.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-131:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha4
                       (was: IDFED-1.0.0.beta1)


> OpenID Integration
> ------------------
>
>                 Key: JBID-131
>                 URL: https://jira.jboss.org/jira/browse/JBID-131
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> Integrate Openid4Java which is ASL 2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 15:31:42 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 15:31:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-133) HTTP/Redirect binding
 : signature validation results are ignored (at the SP side as well as at
 the IDP side)
In-Reply-To: <1448773925.1247683709248.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <614315136.1248377502267.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-133:
-------------------------------

    Summary: HTTP/Redirect binding : signature validation results are ignored (at the SP side as well as at the IDP side)  (was: in the HTTP/Redirect binding, signature validation results are ignored (at the SP side as well as at the IDP side))


> HTTP/Redirect binding : signature validation results are ignored (at the SP side as well as at the IDP side)
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBID-133
>                 URL: https://jira.jboss.org/jira/browse/JBID-133
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Marcel Kolsteren
>            Assignee: Anil Saldhana
>
> When using signatures in the HTTP/Redirect binding, incorrect signatures don't lead to a negative authentication result.
> This is caused by the IDPRedirectValve and the SPRedirectFormAuthenticator. Both classes have a validate method that is overridden by the signature-enabled subclass. In both classes, the validate method is called, but the boolean result is ignored:
>          this.validate(request);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 15:41:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 15:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Work started: (JBID-133) HTTP/Redirect
 binding : signature validation results are ignored (at the SP side as well
 as at the IDP side)
In-Reply-To: <1448773925.1247683709248.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <909965883.1248378089654.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on JBID-133 started by Anil Saldhana.

> HTTP/Redirect binding : signature validation results are ignored (at the SP side as well as at the IDP side)
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBID-133
>                 URL: https://jira.jboss.org/jira/browse/JBID-133
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Marcel Kolsteren
>            Assignee: Anil Saldhana
>
> When using signatures in the HTTP/Redirect binding, incorrect signatures don't lead to a negative authentication result.
> This is caused by the IDPRedirectValve and the SPRedirectFormAuthenticator. Both classes have a validate method that is overridden by the signature-enabled subclass. In both classes, the validate method is called, but the boolean result is ignored:
>          this.validate(request);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 16:05:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 16:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-133) HTTP/Redirect binding
 : signature validation results are ignored (at the SP side as well as at
 the IDP side)
In-Reply-To: <1448773925.1247683709248.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1320338543.1248379529198.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-133:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha5


> HTTP/Redirect binding : signature validation results are ignored (at the SP side as well as at the IDP side)
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBID-133
>                 URL: https://jira.jboss.org/jira/browse/JBID-133
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Marcel Kolsteren
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> When using signatures in the HTTP/Redirect binding, incorrect signatures don't lead to a negative authentication result.
> This is caused by the IDPRedirectValve and the SPRedirectFormAuthenticator. Both classes have a validate method that is overridden by the signature-enabled subclass. In both classes, the validate method is called, but the boolean result is ignored:
>          this.validate(request);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 16:14:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 16:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-133) HTTP/Redirect binding
 : signature validation results are ignored (at the SP side as well as at
 the IDP side)
In-Reply-To: <1448773925.1247683709248.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2089301610.1248380069905.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-133.
------------------------------

    Resolution: Done


> HTTP/Redirect binding : signature validation results are ignored (at the SP side as well as at the IDP side)
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBID-133
>                 URL: https://jira.jboss.org/jira/browse/JBID-133
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Marcel Kolsteren
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> When using signatures in the HTTP/Redirect binding, incorrect signatures don't lead to a negative authentication result.
> This is caused by the IDPRedirectValve and the SPRedirectFormAuthenticator. Both classes have a validate method that is overridden by the signature-enabled subclass. In both classes, the validate method is called, but the boolean result is ignored:
>          this.validate(request);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 16:36:29 2009
From: jira-events at lists.jboss.org (Mike Millson (JIRA))
Date: Thu, 23 Jul 2009 16:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-2403) CMS Conditional
	GET
In-Reply-To: <18649384.1243398117117.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1586896217.1248381389215.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Millson updated JBPORTAL-2403:
-----------------------------------

    Fix Version/s: 2.7.3 Final


> CMS Conditional GET
> -------------------
>
>                 Key: JBPORTAL-2403
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2403
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.7.2 Final
>            Reporter: Mike Millson
>            Assignee: Sohil Shah
>             Fix For: 2.7.3 Final
>
>         Attachments: cms-conditional-get.patch
>
>
> Add support for conditional GET (304 response) for CMS content so clients can serve unmodified files from cache.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 17:13:29 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Thu, 23 Jul 2009 17:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTEST-13)
 JBossTestServices.login cannot let flushAuthCache fail
Message-ID: <1684894614.1248383609128.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBossTestServices.login cannot let flushAuthCache fail
------------------------------------------------------

                 Key: JBTEST-13
                 URL: https://jira.jboss.org/jira/browse/JBTEST-13
             Project: JBoss Test
          Issue Type: Bug
    Affects Versions: 1.1.4.GA
            Reporter: Scott M Stark
            Assignee: Scott M Stark


I created a test setup that set jbosstest.secure to true:

   public static Test suite() throws Exception
   {
      System.setProperty("jbosstest.secure", "true");
      System.setProperty("jbosstest.username", PROFILE_SERVICE_PRINCIPAL);
      System.setProperty("jbosstest.username", PROFILE_SERVICE_CREDENTIALS);
      
      TestSuite suite = new TestSuite();
      suite.addTest(new ProfileServiceUnitTestCase("testNonAdminProfileKeys"));
      suite.addTest(new ProfileServiceUnitTestCase("testProfileKeys"));
      return getDeploySetup(ProfileServiceUnitTestCase.class, suite, "testSecureProxies.beans");
   }

but this fails because the JBossTestServices.login fails because of a call to flushAuthCache before the login information has been set:

10132 [main] DEBUG org.jboss.test.profileservice.testsecure.ProfileServiceUnitTestCase  - args=[other]
java.lang.SecurityException: Failed to authenticate principal=null, securityDomain=jmx-console
	at org.jboss.jmx.connector.invoker.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:88)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
	at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
	at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
	at sun.rmi.transport.Transport$1.run(Transport.java:153)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
	at java.lang.Thread.run(Thread.java:613)
	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
	at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(JRMPInvoker_Stub.java:44)
	at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:133)
	at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
	at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
	at org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor.invoke(InvokerAdaptorClientInterceptor.java:66)
	at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:68)
	at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)
	at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101)
	at $Proxy0.invoke(Unknown Source)
	at org.jboss.test.JBossTestServices.invoke(JBossTestServices.java:239)
	at org.jboss.test.JBossTestServices.invoke(JBossTestServices.java:228)
	at org.jboss.test.JBossTestServices.flushAuthCache(JBossTestServices.java:367)
	at org.jboss.test.JBossTestServices.login(JBossTestServices.java:313)
	at org.jboss.test.JBossTestCase$1.setUp(JBossTestCase.java:301)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)

This needs to be caught and ignored.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 17:20:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 17:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-143) IDPWebBrowserSSOValve
 needs to use the validate method return value
Message-ID: <1837698266.1248384029219.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

IDPWebBrowserSSOValve needs to use the validate method return value
-------------------------------------------------------------------

                 Key: JBID-143
                 URL: https://jira.jboss.org/jira/browse/JBID-143
             Project: JBoss Identity
          Issue Type: Bug
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.alpha5




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 17:20:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 17:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-143) IDPWebBrowserSSOValve
 needs to use the validate method return value
In-Reply-To: <1837698266.1248384029219.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1491480685.1248384029326.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-143.
------------------------------

    Resolution: Done


> IDPWebBrowserSSOValve needs to use the validate method return value
> -------------------------------------------------------------------
>
>                 Key: JBID-143
>                 URL: https://jira.jboss.org/jira/browse/JBID-143
>             Project: JBoss Identity
>          Issue Type: Bug
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 17:23:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 17:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-144)
 SPPostFormAuthenticator needs to use the validate method return value
Message-ID: <46217206.1248384209082.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SPPostFormAuthenticator needs to use the validate method return value
---------------------------------------------------------------------

                 Key: JBID-144
                 URL: https://jira.jboss.org/jira/browse/JBID-144
             Project: JBoss Identity
          Issue Type: Sub-task
    Affects Versions: IDFED-1.0.0.alpha4
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.alpha5




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 17:25:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Thu, 23 Jul 2009 17:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-144)
 SPPostFormAuthenticator needs to use the validate method return value
In-Reply-To: <46217206.1248384209082.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <364795506.1248384329124.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-144.
------------------------------

    Resolution: Done


> SPPostFormAuthenticator needs to use the validate method return value
> ---------------------------------------------------------------------
>
>                 Key: JBID-144
>                 URL: https://jira.jboss.org/jira/browse/JBID-144
>             Project: JBoss Identity
>          Issue Type: Sub-task
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 17:56:29 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Thu, 23 Jul 2009 17:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTEST-13)
 JBossTestServices.login cannot let flushAuthCache fail
In-Reply-To: <1684894614.1248383609128.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1015049189.1248386189241.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBTEST-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBTEST-13.
---------------------------------

    Resolution: Done


> JBossTestServices.login cannot let flushAuthCache fail
> ------------------------------------------------------
>
>                 Key: JBTEST-13
>                 URL: https://jira.jboss.org/jira/browse/JBTEST-13
>             Project: JBoss Test
>          Issue Type: Bug
>    Affects Versions: 1.1.4.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>
> I created a test setup that set jbosstest.secure to true:
>    public static Test suite() throws Exception
>    {
>       System.setProperty("jbosstest.secure", "true");
>       System.setProperty("jbosstest.username", PROFILE_SERVICE_PRINCIPAL);
>       System.setProperty("jbosstest.username", PROFILE_SERVICE_CREDENTIALS);
>       
>       TestSuite suite = new TestSuite();
>       suite.addTest(new ProfileServiceUnitTestCase("testNonAdminProfileKeys"));
>       suite.addTest(new ProfileServiceUnitTestCase("testProfileKeys"));
>       return getDeploySetup(ProfileServiceUnitTestCase.class, suite, "testSecureProxies.beans");
>    }
> but this fails because the JBossTestServices.login fails because of a call to flushAuthCache before the login information has been set:
> 10132 [main] DEBUG org.jboss.test.profileservice.testsecure.ProfileServiceUnitTestCase  - args=[other]
> java.lang.SecurityException: Failed to authenticate principal=null, securityDomain=jmx-console
> 	at org.jboss.jmx.connector.invoker.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:88)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
> 	at java.lang.Thread.run(Thread.java:613)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(JRMPInvoker_Stub.java:44)
> 	at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:133)
> 	at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
> 	at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
> 	at org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor.invoke(InvokerAdaptorClientInterceptor.java:66)
> 	at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:68)
> 	at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)
> 	at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101)
> 	at $Proxy0.invoke(Unknown Source)
> 	at org.jboss.test.JBossTestServices.invoke(JBossTestServices.java:239)
> 	at org.jboss.test.JBossTestServices.invoke(JBossTestServices.java:228)
> 	at org.jboss.test.JBossTestServices.flushAuthCache(JBossTestServices.java:367)
> 	at org.jboss.test.JBossTestServices.login(JBossTestServices.java:313)
> 	at org.jboss.test.JBossTestCase$1.setUp(JBossTestCase.java:301)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> This needs to be caught and ignored.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 17:58:29 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Thu, 23 Jul 2009 17:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTEST-13)
 JBossTestServices.login cannot let flushAuthCache fail
In-Reply-To: <1684894614.1248383609128.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1665554314.1248386309147.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBTEST-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark updated JBTEST-13:
--------------------------------

    Workaround Description: 
You can use a class specific delegate that overrides the login methods, for example:

   public static AbstractTestDelegate getDelegate(Class clazz) throws Exception
   {
      AbstractTestDelegate delegate = new JBossTestServices(clazz)
      {
         @Override
         public void login() throws Exception
         {
            String confName = System.getProperty("conf.name", "profileservice");
            AppCallbackHandler handler = new AppCallbackHandler(PROFILE_SERVICE_PRINCIPAL, PROFILE_SERVICE_CREDENTIALS.toCharArray());
            LoginContext loginContext = new LoginContext(confName, handler);
            loginContext.login();
            System.err.println("login as: "+PROFILE_SERVICE_PRINCIPAL);
         }
         
      };
      return delegate;
   }

                Workaround: [Workaround Exists]


> JBossTestServices.login cannot let flushAuthCache fail
> ------------------------------------------------------
>
>                 Key: JBTEST-13
>                 URL: https://jira.jboss.org/jira/browse/JBTEST-13
>             Project: JBoss Test
>          Issue Type: Bug
>    Affects Versions: 1.1.4.GA
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>
> I created a test setup that set jbosstest.secure to true:
>    public static Test suite() throws Exception
>    {
>       System.setProperty("jbosstest.secure", "true");
>       System.setProperty("jbosstest.username", PROFILE_SERVICE_PRINCIPAL);
>       System.setProperty("jbosstest.username", PROFILE_SERVICE_CREDENTIALS);
>       
>       TestSuite suite = new TestSuite();
>       suite.addTest(new ProfileServiceUnitTestCase("testNonAdminProfileKeys"));
>       suite.addTest(new ProfileServiceUnitTestCase("testProfileKeys"));
>       return getDeploySetup(ProfileServiceUnitTestCase.class, suite, "testSecureProxies.beans");
>    }
> but this fails because the JBossTestServices.login fails because of a call to flushAuthCache before the login information has been set:
> 10132 [main] DEBUG org.jboss.test.profileservice.testsecure.ProfileServiceUnitTestCase  - args=[other]
> java.lang.SecurityException: Failed to authenticate principal=null, securityDomain=jmx-console
> 	at org.jboss.jmx.connector.invoker.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:88)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:180)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:855)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:422)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
> 	at java.lang.Thread.run(Thread.java:613)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(JRMPInvoker_Stub.java:44)
> 	at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:133)
> 	at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
> 	at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
> 	at org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor.invoke(InvokerAdaptorClientInterceptor.java:66)
> 	at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:68)
> 	at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)
> 	at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101)
> 	at $Proxy0.invoke(Unknown Source)
> 	at org.jboss.test.JBossTestServices.invoke(JBossTestServices.java:239)
> 	at org.jboss.test.JBossTestServices.invoke(JBossTestServices.java:228)
> 	at org.jboss.test.JBossTestServices.flushAuthCache(JBossTestServices.java:367)
> 	at org.jboss.test.JBossTestServices.login(JBossTestServices.java:313)
> 	at org.jboss.test.JBossTestCase$1.setUp(JBossTestCase.java:301)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> This needs to be caught and ignored.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 22:40:54 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Jul 2009 22:40:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2204) Exception not
 rethrown by AbstractWorkingMemory.executeQueuedActions()
In-Reply-To: <1550042503.1247265340995.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1828640197.1248403254406.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned JBRULES-2204:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)


> Exception not rethrown by AbstractWorkingMemory.executeQueuedActions() 
> -----------------------------------------------------------------------
>
>                 Key: JBRULES-2204
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2204
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>         Environment: JBoss AS 5.0, Windows Server 2003 SP2, Drools 5.0.1.FINAL
>            Reporter: Tom Murphy
>            Assignee: Edson Tirelli
>
> AbstractWorkingMemory.executeQueuedActions()  catches exceptions thrown within calls to action.execute() (line 1486). 
> It then tests to see if the exception is a RuntimeDroolsException and rethrows it if it is. However, if it is not, it simply does a printStackTrace() on the exception and does not re-throw it. This is a problem because SplitInstance throws an IllegalArgumentException on line 73. This is then caught and gobbled by the catch clause starting on line 1487 of AbstractWorkingMemory.java. 
> The result is that any service or application hosting the Drools runtime will never see this exception. What looks to the user like a clean (albeit overly shortened) rules session has in fact thrown an error, but it is not visible to the user or the owning service. It is therefore very difficult to diagnose why the rules and/or flows are not doing what they should.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 23 22:42:29 2009
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 23 Jul 2009 22:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2204) Exception not
 rethrown by AbstractWorkingMemory.executeQueuedActions()
In-Reply-To: <1550042503.1247265340995.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <146939901.1248403349197.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2204.
----------------------------------

    Fix Version/s: 5.1.0.M1
       Resolution: Done


Rethrowing the exception. 
Thanks for reporting.


> Exception not rethrown by AbstractWorkingMemory.executeQueuedActions() 
> -----------------------------------------------------------------------
>
>                 Key: JBRULES-2204
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2204
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>         Environment: JBoss AS 5.0, Windows Server 2003 SP2, Drools 5.0.1.FINAL
>            Reporter: Tom Murphy
>            Assignee: Edson Tirelli
>             Fix For: 5.1.0.M1
>
>
> AbstractWorkingMemory.executeQueuedActions()  catches exceptions thrown within calls to action.execute() (line 1486). 
> It then tests to see if the exception is a RuntimeDroolsException and rethrows it if it is. However, if it is not, it simply does a printStackTrace() on the exception and does not re-throw it. This is a problem because SplitInstance throws an IllegalArgumentException on line 73. This is then caught and gobbled by the catch clause starting on line 1487 of AbstractWorkingMemory.java. 
> The result is that any service or application hosting the Drools runtime will never see this exception. What looks to the user like a clean (albeit overly shortened) rules session has in fact thrown an error, but it is not visible to the user or the owning service. It is therefore very difficult to diagnose why the rules and/or flows are not doing what they should.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 00:56:29 2009
From: jira-events at lists.jboss.org (Vicky Kak (JIRA))
Date: Fri, 24 Jul 2009 00:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
In-Reply-To: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <895012303.1248411389504.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477384#action_12477384 ] 

Vicky Kak commented on JBAS-7086:
---------------------------------

We have this part of code missing in 
http://anonsvn.jboss.org/repos/jbossas/tags/JBoss_5_0_1_GA/connector/src/main/org/jboss/resource/metadata/mcf/XADataSourceDeploymentMetaData.java

************************************************************************************* 
      if(getIsSameRMOverrideValue() != null)
      {
         property = new ManagedConnectionFactoryPropertyMetaData();
         property.setName("IsSameRMOverrideValue");
         property.setType("java.lang.Boolean");
         property.setValue(String.valueOf(getIsSameRMOverrideValue()));
         properties.add(property);         
      }
************************************************************************************* 

It is already here 
http://anonsvn.jboss.org/repos/jbossas/tags/JBoss_5_1_0_GA/connector/src/main/org/jboss/resource/metadata/mcf/XADataSourceDeploymentMetaData.java

Also check this
https://jira.jboss.org/jira/browse/JBAS-5203

> Can't enlist in transaction with second Oracle XA connection/resource.
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7086
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager (Arjuna)
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: The operating system has been windows, but that doesn't appear to be related.
> Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
>            Reporter: Kevin Bates
>            Assignee: Jesper Pedersen
>
> We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.
> At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:
> 2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
> oracle.jdbc.xa.OracleXAException
> 	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
> 	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
> 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
> com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
> 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
> 	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
> 	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
> 	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:404)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy134.executeChanges(Unknown Source)
> 	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:378)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy135.executeChanges(Unknown Source)
> 	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
> 	at java.security.AccessController.doPrivileged(AccessController.java:284)
> 	at javax.security.auth.Subject.doAs(Subject.java:573)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
> 	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
> 	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:735)
> Caused by: 
> org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
> 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 	... 90 more
> Caused by: 
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 	... 92 more
> Caused by: 
> javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	... 96 more
> The two XA data sources are configured as follows:
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">OS1</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraGCDDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">GCD</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.
> Kind regards.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 05:09:29 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Fri, 24 Jul 2009 05:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6054) @EJB injection in
 JSP fails for local interface
In-Reply-To: <916085.1223412800943.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1882917501.1248426569328.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477400#action_12477400 ] 

Ondrej Medek commented on JBAS-6054:
------------------------------------

This issue is still in 5.1.0GA. It annoying when the EAR name changes, one has to change all mappedNames in the JSP pages.

> @EJB injection in JSP fails for local  interface
> ------------------------------------------------
>
>                 Key: JBAS-6054
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6054
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.0.0.CR2
>            Reporter: Wolfgang Knauf
>            Assignee: Carlo de Wolf
>         Attachments: Stateless.ear
>
>
> I will attach a sample for this problem.
> To verify the code:
> The attached EAR contains EJB, Web and ApplicationClient projects, one EJB "GeometricModelBean" with remote and local interfaces. The web project uses injection, the application client performs a JNDI lookup.
> The JSP  tries to inject a local and a remote interface in "GeometricModelTest.jsp" (http://localhost:8080/StatelessWeb/GeometricModelTest.jsp)
> <%!
>   @EJB()
>   GeometricModelRemote geometricModel;
>   @EJB()
>   GeometricModelLocal geometricModelLocal;
> %>
> The local interface injection will fail with this exception (from server console):
> 21:46:31,421 ERROR [FieldBeanProperty] failed to set value Proxy to jboss.j2ee:ear=Stateless.ear,jar=StatelessEJB.jar,name=GeometricModelBean,service=EJB3 implementing [interface org.jboss.ejb3.proxy.intf.EjbProxy, interface de.fhw.komponentenarchitekturen.knauf.stateless.GeometricModelRemote, interface org.jboss.ejb3.proxy.intf.SessionProxy] on field de.fhw.komponentenarchitekturen.knauf.stateless.GeometricModelLocal org.apache.jsp.GeometricModelTest_jsp.geometricModelLocal
> java.lang.IllegalArgumentException: Can not set de.fhw.komponentenarchitekturen.knauf.stateless.GeometricModelLocal field org.apache.jsp.GeometricModelTest_jsp.geometricModelLocal to $Proxy245
> 	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(Unknown Source)
> 	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(Unknown Source)
> 	at sun.reflect.UnsafeObjectFieldAccessorImpl.set(Unknown Source)
> 	at java.lang.reflect.Field.set(Unknown Source)
> 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:74)
> 	at org.jboss.injection.JndiPropertyInjector.inject(JndiPropertyInjector.java:119)
> 	at org.jboss.web.tomcat.service.TomcatInjectionContainer.processInjectors(TomcatInjectionContainer.java:361)
> 	at org.jboss.web.tomcat.service.TomcatInjectionContainer.processAnnotations(TomcatInjectionContainer.java:404)
> 	at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:261)
> 	at org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:145)
> 	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)
> 	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:322)
> 	.....
> It works, if I specifiy a "mappedName" attribute (pointing to the default bean name).
> <%!
>   @EJB()
>   GeometricModelRemote geometricModel;
>   @EJB(mappedName="Stateless/GeometricModelBean/local")
>   GeometricModelLocal geometricModelLocal;
> %>
> For servlets, the local interface injection works fine (also in the sample at URL http://localhost:8080/StatelessWeb/servlet/GeometricModelServlet)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 08:10:29 2009
From: jira-events at lists.jboss.org (Shital Mehta (JIRA))
Date: Fri, 24 Jul 2009 08:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2199)
 NullPointerException with JPA session persistence in Drools Flow
In-Reply-To: <233050457.1247060645508.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <127002592.1248437429266.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477436#action_12477436 ] 

Shital Mehta commented on JBRULES-2199:
---------------------------------------

Guys,

I hit the same problem. It seems persistence (or may be drools flow itself) is not a yet a widely used feature. I was just about to recommend drools in my company over jBPM 4.0 as I thought rules+workflow is a very powerful combination but will have to wait till drools seriously starts supporting long living workflow sessions.

> NullPointerException with JPA session persistence in Drools Flow
> ----------------------------------------------------------------
>
>                 Key: JBRULES-2199
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2199
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Alan Gairey
>            Assignee: Mark Proctor
>
> I'm currently using Drools Flow with JPA session persistence enabled as described in section 5.1 of the User Guide.
> As a process executes, session information is saved to the H2 database correctly.
> The problem comes when recreating a session from its persisted state, using the code:
> {code}
> // recreate the session from database using the sessionId
> ksession = JPAKnowledgeService.loadStatefulKnowledgeSession( sessionId, kbase, null, env );
> {code}
> This gives me a NullPointerException.
> Having looked into the Drools Flow source code, I think the problem is in the class drools-persistence-jpa\src\main\java\org\drools\persistence\session\SingleSessionCommandService.java.
> The 4th constructor of this class (starting line 132) is called as part of the loading of a knowledge session from the H2 database (i.e. via the code above); this in turn leads to the afterCompletion method of the inner class SynchronizationImpl being called. The final two lines of this method are:
> {code}
> ((JPAProcessInstanceManager) ((ReteooWorkingMemory) session).getProcessInstanceManager()).clearProcessInstances();
> ((JPAWorkItemManager) ((ReteooWorkingMemory) session).getWorkItemManager()).clearWorkItems();
> {code}
> However, when called via the route described above, the session member variable of SingleSessionCommandService has not been set, thus causing the NullPointerException.
> (Interestingly, running the unit tests for drools-persistence-jpa does result in a NullPointerException being thrown multiple times, although the tests are still listed as having passed.)
> I believe enclosing the above two lines as follows will fix the problem:
> {code}
> if (session != null) { 
>     ((JPAProcessInstanceManager) ((ReteooWorkingMemory) session).getProcessInstanceManager()).clearProcessInstances(); 
>     ((JPAWorkItemManager) ((ReteooWorkingMemory) session).getWorkItemManager()).clearWorkItems(); 
> } 
> {code}
> Also, in the 4th constructor of SingleSessionCommandService, after the session has been set, the following line needs to be added to ensure the session id is the same as the session info id:
> {code}
> ((ReteooStatefulSession) this.session).setId( this.sessionInfo.getId() );
> {code}
> (This line _is_ present at the end of the 3rd constructor - line 123.)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 09:09:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 24 Jul 2009 09:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
In-Reply-To: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1969570085.1248440969420.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBAS-7086:
----------------------------------

    Fix Version/s: JBossAS-5.1.0.GA


> Can't enlist in transaction with second Oracle XA connection/resource.
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7086
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager (Arjuna)
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: The operating system has been windows, but that doesn't appear to be related.
> Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
>            Reporter: Kevin Bates
>            Assignee: Jesper Pedersen
>             Fix For: JBossAS-5.1.0.GA
>
>
> We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.
> At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:
> 2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
> oracle.jdbc.xa.OracleXAException
> 	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
> 	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
> 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
> com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
> 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
> 	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
> 	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
> 	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:404)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy134.executeChanges(Unknown Source)
> 	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:378)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy135.executeChanges(Unknown Source)
> 	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
> 	at java.security.AccessController.doPrivileged(AccessController.java:284)
> 	at javax.security.auth.Subject.doAs(Subject.java:573)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
> 	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
> 	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:735)
> Caused by: 
> org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
> 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 	... 90 more
> Caused by: 
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 	... 92 more
> Caused by: 
> javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	... 96 more
> The two XA data sources are configured as follows:
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">OS1</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraGCDDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">GCD</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.
> Kind regards.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 09:11:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 24 Jul 2009 09:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
In-Reply-To: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2111977952.1248441089788.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen closed JBAS-7086.
---------------------------------

    Resolution: Done


> Can't enlist in transaction with second Oracle XA connection/resource.
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7086
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: The operating system has been windows, but that doesn't appear to be related.
> Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
>            Reporter: Kevin Bates
>            Assignee: Jesper Pedersen
>             Fix For: JBossAS-5.1.0.GA
>
>
> We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.
> At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:
> 2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
> oracle.jdbc.xa.OracleXAException
> 	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
> 	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
> 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
> com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
> 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
> 	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
> 	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
> 	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:404)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy134.executeChanges(Unknown Source)
> 	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:378)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy135.executeChanges(Unknown Source)
> 	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
> 	at java.security.AccessController.doPrivileged(AccessController.java:284)
> 	at javax.security.auth.Subject.doAs(Subject.java:573)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
> 	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
> 	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:735)
> Caused by: 
> org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
> 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 	... 90 more
> Caused by: 
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 	... 92 more
> Caused by: 
> javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	... 96 more
> The two XA data sources are configured as follows:
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">OS1</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraGCDDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">GCD</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.
> Kind regards.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 09:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 24 Jul 2009 09:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
In-Reply-To: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1449133197.1248441090204.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen reopened JBAS-7086:
-----------------------------------



> Can't enlist in transaction with second Oracle XA connection/resource.
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7086
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: The operating system has been windows, but that doesn't appear to be related.
> Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
>            Reporter: Kevin Bates
>            Assignee: Jesper Pedersen
>             Fix For: JBossAS-5.1.0.GA
>
>
> We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.
> At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:
> 2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
> oracle.jdbc.xa.OracleXAException
> 	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
> 	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
> 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
> com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
> 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
> 	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
> 	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
> 	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:404)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy134.executeChanges(Unknown Source)
> 	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:378)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy135.executeChanges(Unknown Source)
> 	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
> 	at java.security.AccessController.doPrivileged(AccessController.java:284)
> 	at javax.security.auth.Subject.doAs(Subject.java:573)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
> 	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
> 	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:735)
> Caused by: 
> org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
> 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 	... 90 more
> Caused by: 
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 	... 92 more
> Caused by: 
> javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	... 96 more
> The two XA data sources are configured as follows:
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">OS1</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraGCDDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">GCD</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.
> Kind regards.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 09:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 24 Jul 2009 09:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
In-Reply-To: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <53841627.1248441090544.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBAS-7086:
----------------------------------

    Component/s: JCA service
                     (was: Transaction Manager (Arjuna))


> Can't enlist in transaction with second Oracle XA connection/resource.
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7086
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: The operating system has been windows, but that doesn't appear to be related.
> Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
>            Reporter: Kevin Bates
>            Assignee: Jesper Pedersen
>             Fix For: JBossAS-5.1.0.GA
>
>
> We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.
> At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:
> 2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
> oracle.jdbc.xa.OracleXAException
> 	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
> 	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
> 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
> com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
> 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
> 	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
> 	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
> 	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:404)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy134.executeChanges(Unknown Source)
> 	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:378)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy135.executeChanges(Unknown Source)
> 	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
> 	at java.security.AccessController.doPrivileged(AccessController.java:284)
> 	at javax.security.auth.Subject.doAs(Subject.java:573)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
> 	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
> 	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:735)
> Caused by: 
> org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
> 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 	... 90 more
> Caused by: 
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 	... 92 more
> Caused by: 
> javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	... 96 more
> The two XA data sources are configured as follows:
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">OS1</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraGCDDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">GCD</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.
> Kind regards.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 09:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 24 Jul 2009 09:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7086) Can't enlist in
 transaction with second Oracle XA connection/resource.
In-Reply-To: <777718755.1247091291595.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1632084842.1248441090872.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen closed JBAS-7086.
---------------------------------

    Resolution: Done


> Can't enlist in transaction with second Oracle XA connection/resource.
> ----------------------------------------------------------------------
>
>                 Key: JBAS-7086
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7086
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: The operating system has been windows, but that doesn't appear to be related.
> Oracle 11g is in use with 11.1.* or 10.2.* drivers.  We suspect the Oracle version doesn't matter either.
>            Reporter: Kevin Bates
>            Assignee: Jesper Pedersen
>             Fix For: JBossAS-5.1.0.GA
>
>
> We are experiencing the following exception chain when attempting to enlist a secound XA data source into a transaction. This only occurs on Oracle and only on JBoss 5.0.1 GA.  We run the same software against JBoss 4.0.5, WebLogic and WebSphere with SQLServer and DB2 databases as well.  Only this configuration gives us issues - SQLServer and DB2 behave as expected.  In addition, transactions against a single XA connection work fine.
> At the point we go to obtain a connection on the second XA data source, we get the following (commonly posted) exception information:
> 2009-07-08 14:19:51,484 WARN  [org.jboss.resource.connectionmanager.TxConnectionManager] (http-127.0.0.1-8080-1) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener at 4cde4cde[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c handles=0 lastUse=1247087991484 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool at 39e939e9 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool at 5c7c5c7c xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 4c7c4c7c txSync=null]
> oracle.jdbc.xa.OracleXAException
> 	at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1600)
> 	at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:351)
> 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) java.lang.IllegalMonitorStateException
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:138)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1186)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:442)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.unlock(BaseWrapperManagedConnection.java:277)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:235)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:500)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:908)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:662)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 2009-07-08 14:19:51,515 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 2009-07-08 14:19:51,531 ERROR [STDERR] (http-127.0.0.1-8080-1) 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> <deleted due to 32K requirement>
> 2009-07-08 14:19:51,578 ERROR [org.jboss.ejb.plugins.LogInterceptor] (http-127.0.0.1-8080-1) RuntimeException in method: public abstract com.filenet.apiimpl.transport.ExecuteChangesResponse com.filenet.engine.ejb.EngineCoreLocal.executeChanges(com.filenet.apiimpl.transport.ClientCallContext,com.filenet.apiimpl.transport.ExecuteChangesRequest):
> com.filenet.api.exception.EngineRuntimeException: E_FAILED_TO_GET_DATASOURCE: Failed to get DataSource OraDSXA.
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:942)
> 	at com.filenet.engine.context.ServerCallContext.getConnection(ServerCallContext.java:895)
> 	at com.filenet.engine.context.ServerCallContext._getDBContext(ServerCallContext.java:653)
> 	at com.filenet.engine.context.ServerCallContext.getDBContextFromJNDIValues(ServerCallContext.java:826)
> 	at com.filenet.engine.dbpersist.DBContext.determineDatabaseType(DBContext.java:661)
> 	at com.filenet.engine.persist.ObjectStorePersister.preExecuteChange(ObjectStorePersister.java:287)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChangeWork(BaseGCDPersister.java:244)
> 	at com.filenet.engine.persist.IndependentPersister.executeChange(IndependentPersister.java:235)
> 	at com.filenet.engine.persist.BaseGCDPersister.executeChange(BaseGCDPersister.java:153)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1244)
> 	at com.filenet.engine.jca.impl.RequestBrokerImpl.executeChanges(RequestBrokerImpl.java:1126)
> 	at com.filenet.engine.ejb.EngineCoreBean._executeChanges(EngineCoreBean.java:601)
> 	at com.filenet.engine.ejb.EngineCoreBean.executeChanges(EngineCoreBean.java:567)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:404)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy134.executeChanges(Unknown Source)
> 	at com.filenet.engine.ejb.EngineBean.executeChanges(EngineBean.java:658)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> 	at java.lang.reflect.Method.invoke(Method.java:599)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:386)
> 	at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:228)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:156)
> 	at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:173)
> 	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:378)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:267)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:211)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:134)
> 	at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invoke(PreSecurityInterceptor.java:81)
> 	at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
> 	at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:650)
> 	at org.jboss.ejb.Container.invoke(Container.java:1029)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:436)
> 	at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:103)
> 	at $Proxy135.executeChanges(Unknown Source)
> 	at com.filenet.apiimpl.transport.ejb.EnginePortLocal.executeChanges(EnginePortLocal.java:43)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst$1.run(ServiceSessionNst.java:1110)
> 	at java.security.AccessController.doPrivileged(AccessController.java:284)
> 	at javax.security.auth.Subject.doAs(Subject.java:573)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtil.runAs(J2EEAuthnUtil.java:533)
> 	at com.filenet.apiimpl.authentication.util.J2EEAuthnUtilJB.runAs(J2EEAuthnUtilJB.java:280)
> 	at com.filenet.apiimpl.util.J2EEUtilJB.doAs(J2EEUtilJB.java:103)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sMakeInternalEJBCall(ServiceSessionNst.java:977)
> 	at com.filenet.apiimpl.wsi.ServiceSessionNst.sHandleIncomingRequest(ServiceSessionNst.java:915)
> 	at com.filenet.engine.wsi.ListenerNst.service(ListenerNst.java:127)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	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:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 	at java.lang.Thread.run(Thread.java:735)
> Caused by: 
> org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >))
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
> 	at com.filenet.engine.context.ServerCallContext$GetConnection.run(ServerCallContext.java:1430)
> 	at com.filenet.engine.context.ServerCallContext.getConnectionWithRetry(ServerCallContext.java:917)
> 	... 90 more
> Caused by: 
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:409)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:625)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:499)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
> 	at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
> 	... 92 more
> Caused by: 
> javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: 9318dfb:dc6:4a550cf3:67 status: ActionStatus.ABORT_ONLY >
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:879)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:675)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:403)
> 	... 96 more
> The two XA data sources are configured as follows:
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">OS1</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> <datasources>
>  <xa-datasource>
>       <jndi-name>OraGCDDSXA</jndi-name>
>       <use-java-context>false</use-java-context>
> 		<set-tx-query-timeout/>
>       <track-connection-by-tx/>
>       <isSameRM-override-value>false</isSameRM-override-value>
>       <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
>       <xa-datasource-property name="URL">jdbc:oracle:thin:@myserver:1522:SONATADB</xa-datasource-property>
>       <xa-datasource-property name="User">GCD</xa-datasource-property>
>       <xa-datasource-property name="Password">xxxx</xa-datasource-property>
>       <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
>       <no-tx-separate-pools/>
>       <metadata>
>       <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
>           <type-mapping>Oracle9i</type-mapping>
>       </metadata>
>   </xa-datasource>
> </datasources>
> We've tried a number of things (various JDBC driver versions (11.1.0.7, 10.2.0.4), combining data source stanzas into single files, changing the type-mappings, toggling various setting via JMX console, reading the FAQs, google hits, Oracle metalink, etc.) and have not found anything that works.  Given that this same database works fine when referenced from JB 4.0.5 (or any other application server) and that one difference between 4.0.5 and 5.0.1 is the transaction manager, we believe you are our last resource to help resolve this critical issue.  We believe there's some configurable item - unfamiliar to us and, likely, not well-documented, that we must be missing, but don't know where to look next.  Any direction on this matter would be greatly appreciated.  We are happy to provide you with any information you need.
> Kind regards.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 09:26:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 24 Jul 2009 09:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1506) Remove JMS &
 JDNI dependencies from MessagingXAResourceRecovery bean for JBoss AS 5.0
In-Reply-To: <12930667.1234454924508.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <864575658.1248441989368.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated JBMESSAGING-1506:
-------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=158856


> Remove JMS & JDNI dependencies from MessagingXAResourceRecovery bean for JBoss AS 5.0
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1506
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1506
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> POJO rather than MBean

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 09:26:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 24 Jul 2009 09:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1506) Remove JMS &
 JDNI dependencies from MessagingXAResourceRecovery bean for JBoss AS 5.0
In-Reply-To: <12930667.1234454924508.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1006286364.1248441989606.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1506.
------------------------------------

    Resolution: Done


fixed in the trunk

> Remove JMS & JDNI dependencies from MessagingXAResourceRecovery bean for JBoss AS 5.0
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1506
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1506
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> POJO rather than MBean

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 09:32:29 2009
From: jira-events at lists.jboss.org (Tihomir Surdilovic (JIRA))
Date: Fri, 24 Jul 2009 09:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7121) Upgrade to JSF
 1.2_13 in AS 5.x and trunk (6.x)
Message-ID: <716167156.1248442349151.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade to JSF 1.2_13 in AS 5.x and trunk (6.x) 
------------------------------------------------

                 Key: JBAS-7121
                 URL: https://jira.jboss.org/jira/browse/JBAS-7121
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JSF
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Tihomir Surdilovic
            Assignee: Stan Silvert


Upgrade to JSF 1.2_13 in AS 5.x and trunk (6.x).

 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:34:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 24 Jul 2009 11:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1672) AS 5 MBean
 Server integration
In-Reply-To: <32421204.1246267076495.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1080581803.1248449669371.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1672.
------------------------------------

    Resolution: Done


integration has been done but a bug in the jmx-console prevents to update attributes value for queues & addresses MBeans

> AS 5 MBean Server integration
> -----------------------------
>
>                 Key: JBMESSAGING-1672
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1672
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 2.0.0.beta3
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> When JBoss Messaging is integrated in AS 5, it should use AS 5's MBeanServer instead of the JVM's Platform MBeanServer to ensure JBoss Messaging is manageable through AS 5 jmx-console

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:32 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1675) add netty
 servlet firewall support when available.
In-Reply-To: <636963632.1246442671919.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1779502723.1248449912901.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1675:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> add netty servlet firewall support when available.
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1675
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1675
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 2.0.0.beta3
>            Reporter: Andy Taylor
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:33 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1671) Consider
 storing JMS destinations in their own journal instance
In-Reply-To: <11315556.1246092896416.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <687682251.1248449913069.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1671:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Consider storing JMS destinations in their own journal instance
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1671
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1671
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> We should consider storing JMS destinations in their own journal instance, and automatically deploy them into JNDI and management from this. This would mean that any JMS destinations created via the management interface would get redeployed on startup, which is not currently the case

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:33 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1666) Add
 "messageCount" attribute on Address MBean
In-Reply-To: <18851986.1245825537257.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1053371094.1248449913244.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1666:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Add "messageCount" attribute on Address MBean
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1666
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1666
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Value shown in "messageCount" attribute of a queue MBean does not include the number of messages that are paged. This is because messages are paged to disk  before they are routed in the postoffice. So, for the user to be able to find the total number of messages that are added to a queue, Tim suggested that, we add a "messageCount" attribute to the Address MBean. That would indicate how many messages are paged for a particular destination address.  Please refer http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157325 for details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:33 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1649) redesign
 management replication
In-Reply-To: <1828892.1244729756776.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <884190512.1248449913387.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1649:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> redesign management replication
> -------------------------------
>
>                 Key: JBMESSAGING-1649
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1649
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> In order for management operation using JMX to be replicated, the MBeans are translating the management
> operation to a management messages which is sent to the management address using Core API. This allows
> for management messages to be properly replicated.
> However this allow forces the server to have an acceptor and a connector to talk to *itelsf* which is configusing
> and clutter the server configuration.
> The management code should be redesigned to be plugged directly on the server-side. The management 
> service'd no longer send a Core message using the Core API. Instead it'd call directly the ServerSessionPacketHandler
> (or equivalent) to handle a packet corresponding to the management message. It'll work since the handler will then
> replicate the packet correctly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:33 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1645)
	Multi-threaded replication
In-Reply-To: <19987581.1244635916851.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <905056941.1248449913539.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1645:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Multi-threaded replication
> --------------------------
>
>                 Key: JBMESSAGING-1645
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1645
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> Currently replication between live and backup node is done on a single thread. The operation is replicated, executed on backup, and when the result is returned to live, it is executed on live before the result is returned to the client (if applicable). This ensures the same ordering of state changes on live and backup but effectively makes all operation single threaded, thus reducing throughput in a clustered set-up.
> Instead we should implement multi-threaded replication. If replicated operations are being executed concurrently on backup it is more tricky to ensure that state changes on any object occur in the  same order as on live but it is possible.
> This is how we can do it.
> For the following types of objects it is important that their state changes occur in the same order on live and backup
> 1) Sessions (S)
> 2) Queues (Q)
> 3) Post offices. (P)
> Operations that occur on the live node are either
> a) Initiated externally - e.g. an operation like send message or acknowledge coming from a client
> b) Initiated internally - e.g. an asynchronous delivery, a depage, or an asynchronous message expiry from the reaper
> As any of these operations are being executed they may affect the state of one or more stateful objects, e.g. a send operation might affect the state of S1, Q1, Q2, S2, and S3 (as a sent message is routed to Q1 and Q2 and immediately delivered to S2 and S3).
> When the operation is replicated to the backup we must ensure that the state changes on any affected stateful objects must occur in the same order as they did on live.
> To do this as the operation is executed and the state changes occur, each stateful object is locked in turn, and a sequence number is obtained from the stateful object which tells us we're the nth stateful operation on that object.
> So a send operation might end up with a set of state sequences numbers:
> S1(12), Q1(102), Q2(32), S2 (74), S3 (1038)
> Which tells us the operation cause the 12th state change on object S1, followed by the 102nd state change on object Q1 etc.
> The list of sequence numbers can be stored in a thread local as the operation is executed on live.
> When the operation is executed on live we delay sending back any data to the client until we have replicate the operation to the backup and got a response that the replication has been processed.
> To ensure the state changes occur in the same order on backup, when we replicate the operation we also replicate the list state sequence numbers. When the operation is executed on the backup we attempt to obtain the locks on the stateful objects.
> Say we try to get the lock on object Q1, but the current sequence number of the object Q1 on the backup is 100, the attempt to get the lock will block until the 101st state change is executed since we require that operation is the 102nd state change.
> By using such a technique we can ensure that state changes are obtained in the same order on live and backup but are not limited to a single thread.
> In many cases the objects will be in the expected or similar sequence numbers so the replications can occur in parallel.
> In case of failure of the live node, operations may block indefinitely on the backup waiting for replications to arrive for missing state changes.
> For this we can timeout on the lock and reverse state changes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:33 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1635) Refactor
 HA-JNDI example to provide a real clustering test
In-Reply-To: <17016301.1243435835076.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1716073512.1248449913682.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1635:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Refactor HA-JNDI example to provide a real clustering test
> ----------------------------------------------------------
>
>                 Key: JBMESSAGING-1635
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1635
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Jeff Mesnil
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> our current javaee/hajndi does nothing (apart from opening connections)
> the example should be enhanced to demonstrate clustering feature *and* should
> be better automated (wrt to deployment and server starts/stops)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:33 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1626) The
 replicated queue could get out of order after Depage
In-Reply-To: <15212228.1242232787348.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1734484023.1248449913844.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1626:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> The replicated queue could get out of order after Depage
> --------------------------------------------------------
>
>                 Key: JBMESSAGING-1626
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1626
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> In an edge case scenario, where there are too many subscriptions during page/depage the backup node queue could get out of order what would cause issues with replicateDelivery.
> similar to what happened on JBMESSAGING-1558

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:33 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1609) Provide
 Destination deploying through Beans
In-Reply-To: <12195779.1240853506474.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1480733777.1248449913978.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1609:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Provide Destination deploying through Beans
> -------------------------------------------
>
>                 Key: JBMESSAGING-1609
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1609
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> This should be very simple to implement.
> An user may choose to deploy a destination using Beans, so he could hot-deploy queues with his applications in a way it would work with MDBs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:34 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1601) JMSBridge
 won't work with LargeMessages and resend
In-Reply-To: <12004607.1239904702467.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1270846338.1248449914134.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1601:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> JMSBridge won't work with LargeMessages and resend
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1601
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1601
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> The JMS Bridge is caching a Message, and resending it when a failure occurs.
> On the case of a LargeMessage, the message should be received again instead of cached.
> Actually caching won't work with LargeMessages at all.
> There should be a config on JMSBridge that would complete disable caching, and the message would be received again in case of failure on either side (src or dest address). The user would need then to configure the JMSBridge accordingly to LargeMessages if that feature is being used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:34 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1589) Soak tests
In-Reply-To: <10099911.1239023242682.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <407958377.1248449914250.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1589:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Soak tests
> ----------
>
>                 Key: JBMESSAGING-1589
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1589
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Add soak tests.
> For normal use cases+ failover, paging etc.
> Should run for several days.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:34 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1588) Add netty
	bridge tests
In-Reply-To: <23146682.1239023123744.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <974893598.1248449914345.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1588:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Add netty bridge tests
> ----------------------
>
>                 Key: JBMESSAGING-1588
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1588
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:34 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1587) Add trace
	logging
In-Reply-To: <26091288.1239023123317.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <607712787.1248449914458.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1587:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Add trace logging
> -----------------
>
>                 Key: JBMESSAGING-1587
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1587
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Add trace logging throughout, will aid in diagnosing issues in a production environment.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:34 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1584) Client side
 load balancing integration tests
In-Reply-To: <16160411.1239022283313.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1816231999.1248449914562.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1584:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Client side load balancing integration tests
> --------------------------------------------
>
>                 Key: JBMESSAGING-1584
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1584
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> We need tests for this, that test different policies etc.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:34 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1583) Fix message
 redistribution with replication
In-Reply-To: <28198275.1239022282568.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <53210970.1248449914676.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1583:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Fix message redistribution with replication
> -------------------------------------------
>
>                 Key: JBMESSAGING-1583
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1583
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> Message redistribution in a replicated cluster is currently broken. Needs to be fixed and thoroughly tested.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:34 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1572) Sent to DLQ
 if routeFromCluster fails
In-Reply-To: <6577331.1239017542713.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1576467953.1248449914777.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1572:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Sent to DLQ if routeFromCluster fails
> -------------------------------------
>
>                 Key: JBMESSAGING-1572
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1572
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> If routeFromCluster fails e.g. if queue has been deleted after sending on source, then message should go to DLQ not be deleted.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:34 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1570) Why does
 QueueImpl::changeMessagePriority delete the ref?
In-Reply-To: <3627699.1239016823311.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1760101156.1248449914948.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1570:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Why does QueueImpl::changeMessagePriority delete the ref?
> ---------------------------------------------------------
>
>                 Key: JBMESSAGING-1570
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1570
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> QueueImpl::changeMessagePriority seems to delete the old ref from storage then only add the new one in memory!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:35 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1569) Add test for
 failing onto backup, then copying backup dir
In-Reply-To: <14314443.1239016463248.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2050906689.1248449915037.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1569:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Add test for failing onto backup, then copying backup dir
> ---------------------------------------------------------
>
>                 Key: JBMESSAGING-1569
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1569
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Add a test for server failing over to backup doing some work, closing both down, then copying over data directory from backup to live and restarting

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:35 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1567) Statically
 wired clusters and initial/reconnection
In-Reply-To: <7470014.1239016342551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1257084863.1248449915170.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1567:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Statically wired clusters and initial/reconnection
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1567
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1567
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Statically wired clusters have problems  when a node fails, since the backup node will try and connect its bridges to the failed node when activated and just get into an endless loop doing that, since the connection manager will always try and connect on the first node

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:35 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1566) Temporary
 Destinations should not allow their consumers to be created on other
 connections than their own as per JMS spec
In-Reply-To: <18089367.1238683225226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <760823051.1248449915294.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1566:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Temporary Destinations should not allow their consumers to be created on other connections than their own as per JMS spec
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1566
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1566
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Howard Gao
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> JMS 1.1 spec Section 4.4.3 2nd paragraph:
> Temporary destinations (TemporaryQueue or TemporaryTopic objects) are
> destinations that are system-generated uniquely for their connection. Only
> their own connection is allowed to create MessageConsumers for them.
> So the following test should fail, but currently it passes.
>    public void testTemporaryQueueScope()
>    {
>       try
>       {
>          senderConnection.stop();
>          receiverConnection.stop();
>          tempQueue = receiverSession.createTemporaryQueue();
>          //create consumer on different connection, should fail!
>          senderSession.createConsumer(tempQueue);
>       }
>       catch (JMSException e)
>       {
>          fail(e);
>       }
>    }
> The same issue exists with temporary topics too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:35 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1565) Need to check
 permissions on create producer for JMS
In-Reply-To: <21193950.1238568922429.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <829079277.1248449915373.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1565:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Need to check permissions on create producer for JMS
> ----------------------------------------------------
>
>                 Key: JBMESSAGING-1565
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1565
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> For JMS, we need to check permissions when creating a JMS message producer. However if we do this in JBossSession (currently commented out), then sending management messages to JMS fails since there is no actual management queue.
> The code in JBossSession is temporarily commented out until this is resolved.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:32 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1687) Transaction
 management/demarcation and ack modes/session creation broken in JCA RA
In-Reply-To: <615256574.1247823389304.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1618164653.1248449912645.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1687:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Transaction management/demarcation and ack modes/session creation broken in JCA RA
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1687
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1687
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Andy Taylor
>            Priority: Critical
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:32 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1686) Add more
 transactional options for the JCA adapter
In-Reply-To: <301051903.1247758289359.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <750875441.1248449912781.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1686:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Add more transactional options for the JCA adapter
> --------------------------------------------------
>
>                 Key: JBMESSAGING-1686
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1686
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>
> It should be possible to configure transactions for MDBs in a better fashion. Like receiving messages non-transactionally, or batching a number of transactions, even if this would mean non-compliant but activated by the user's choice.
> We already have:
> - Local Transaction
> - XA Transaction
> The options I'm thinking:
> We should add:
> - Batching transactions (commit on every X records... like most users do when processing a high number of messages outside the application server)
> - NonTransactional (messages being received non transactionally.. what should be good for Non Persistent Messages)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:35 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1557) Race
 condition in JMS Bridge between enlisting the XAResource in the TX and
 message delivery
In-Reply-To: <19430245.1237906402584.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <174663418.1248449915490.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1557:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Race condition in JMS Bridge between enlisting the XAResource in the TX and message delivery
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1557
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1557
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Jeff Mesnil
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> The JMS Bridge code is enlisting the XAResource in the JTA Transaction in a way that can occur concurrently with delivery.
> more info: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=151340&start=10

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:35 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1556) Add
 additional core management notifications
In-Reply-To: <4089038.1237901302475.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1910316261.1248449915635.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1556:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Add additional core management notifications
> --------------------------------------------
>
>                 Key: JBMESSAGING-1556
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1556
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Add additional management notifications for the following events in JBM server:
> 1/ notifications for start/stop of some messaging component: 
> - ACCEPTOR_STARTED / ACCEPTOR_STOPPED 
> - BRIDGE_STARTED / BRIDGE_STOPPED 
> - BROADCAST_GROUP_STARTED / BROADCAST_GROUP_STOPPED 
> - CLUSTER_CONNECTION_STARTED / CLUSTER_CONNECTION_STOPPED 
> - DISCOVERY_GROUP_STARTED / DISCOVERY_GROUP_STOPPED 
> 2/ I was also thinking to add notifications when messages are expired/moved to the dead letter address but I'm not sure these notifications should be enabled by default (they can potentially generate a lot of notifications): 
> EXPIRED_MESSAGE -> when a message is expired 
> MOVED_TO_DEAD_LETTER_ADDRESS -> when a message is moved to the DLA 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:35 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1553) Record list
 of heuristically committed/rolledback transaction branches
In-Reply-To: <1117527.1237565242427.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1516981622.1248449915758.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1553:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Record list of heuristically committed/rolledback transaction branches
> ----------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1553
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1553
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Currently when heuristically committing or rolling back a transaction branch via the management interface we don't record the list of Xids for the committed/rolled back branches.
> If the tx mgr calls commit/rollback and we have already heuristically committed/rolled back then we need to return XA_HEURCOM, so we need the list persisted in order to do this.
> When the tx mgr calls forget, then we can remove them.
> We should add a management method to list the two lists.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:36 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1484) Rename base
	package name
In-Reply-To: <17920878.1231877584176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1289326451.1248449916520.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1484:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Rename base package name
> ------------------------
>
>                 Key: JBMESSAGING-1484
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1484
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Rename org.jboss.messaging to something else.
> Suggestions are:
> org.jboss.jbm
> ....

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:36 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1463) Possible
 Orphaned Files On LargeMessages
In-Reply-To: <31199513.1228862686838.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1309629825.1248449916649.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1463:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Possible Orphaned Files On LargeMessages
> ----------------------------------------
>
>                 Key: JBMESSAGING-1463
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1463
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> If the server crash after the .tmp file is renamed, and before it is added to Journal or Paging, it may be orphaned.
> The possible fix would probably be to inspect the Page and Journal Files and find out what files are orphaned. 
> Maybe we could delay the verification until an user with admin privileges request to identify orphaned files through management.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:36 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1536) Optimisation
In-Reply-To: <9922377.1236104062518.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <586793703.1248449916161.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1536:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Optimisation
> ------------
>
>                 Key: JBMESSAGING-1536
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1536
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Various system optimisations:
> 1) Optimise message routing. We can probably combine preroute and route. Also in BindingsImpl we can  avoid creation of so many sets, and use array based logic instead.
> 2) Optimise SimpleString - intern() where appropriate
> 3) Optimise journal direct byte buffers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:36 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1528) Re-enable
 producer flow control when adress is full
In-Reply-To: <31530726.1236100462526.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <791582351.1248449916287.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1528:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Re-enable producer flow control when adress is full
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1528
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1528
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> This can be done by holding back packet confirmations until more space frees up.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:36 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1526) Improve
 timeout when closing consumer
In-Reply-To: <20211796.1236099982846.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2105813072.1248449916382.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1526:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Improve timeout when closing consumer
> -------------------------------------
>
>                 Key: JBMESSAGING-1526
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1526
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Currently if there are a lot of messages in a client consumer buffer and they are being consumed by a slow consumrt, then on close, it will timeout since it will wait for all messages to be consumed. Need to improve this so it only waits for the current one to complete.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:36 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1433) Enable
 replication for browsers
In-Reply-To: <3332141.1224406292113.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1492917767.1248449916772.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1433:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Enable replication for browsers
> -------------------------------
>
>                 Key: JBMESSAGING-1433
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1433
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> Making a copy of the queue for a browser consumer doesn't work well with replication since
> When replicating the create consumer (browser) to the backup, when executed on the backup the
> backup may have different messages in its queue since been added on different threads.
> So when replicating deliveries they may not be found.
> Uncomment MultiThreadRandomFailoverTest::testM when this is complete.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:36 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1432)
 ReceiveImmediate on consumer should check the server for messages
In-Reply-To: <2499468.1224263600985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1342193053.1248449916909.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1432:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> ReceiveImmediate on consumer should check the server for messages
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-1432
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1432
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Andy Taylor
>            Assignee: Tim Fox
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> When receiveImmediate() is called on a client consumer it only checks its internal buffer. It should also check with the server to make sure there are no messages in transit or waiting to be delivered. Once this is done the Queue Browser can be changed to use this instead of a timeout receive.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:37 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1427) Journal
	Cleanup
In-Reply-To: <6551971.1222785211162.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1756330686.1248449917028.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1427:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Journal Cleanup
> ---------------
>
>                 Key: JBMESSAGING-1427
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1427
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 2.0.0 Alpha
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> If a destination is lazy, not consuming messages for a long time, the journal will grow until those messages are consumed.
> This would be a problem with DLQs or messages taking days before they are consumed.
> Since we inform the TransactionSummary on commits, we could change the journal to support multiple current-files based on configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:37 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1424) Provider
 strict message ordering via "ordering groups"
In-Reply-To: <25015723.1222415841133.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <400847157.1248449917135.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1424:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Provider strict message ordering via "ordering groups"
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1424
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1424
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> See linked task

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:37 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1335) Network
 disconnect reconnect testing
In-Reply-To: <8721677.1211911069404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <921848019.1248449917734.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1335:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Network disconnect reconnect testing
> ------------------------------------
>
>                 Key: JBMESSAGING-1335
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1335
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> We need to do full network disconnect reconnect testing with JBM2.0. For bridge, for split brain etc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:37 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1330) Allow maxSize
 (etc) to be specified when creating a queue using core API
In-Reply-To: <1151134.1211908139552.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1240911584.1248449917867.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1330:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Allow maxSize (etc) to be specified when creating a queue using core API
> ------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1330
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1330
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:38 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1325) Sync a backup
 server with a live server
In-Reply-To: <2662823.1211906159940.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2016758875.1248449918335.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1325:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Sync a backup server with a live server
> ---------------------------------------
>
>                 Key: JBMESSAGING-1325
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1325
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> If a live server has no backup server, should be able to bring one up while the live is running and for them to auto-sync.
> This is useful if the server has failed over to its backup, and you won't to bring up another backup for the failed over server.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:38 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1316) code cleanup
 - final fields and params
In-Reply-To: <14607629.1211904890487.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2128563076.1248449918744.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1316:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> code cleanup - final fields and params
> --------------------------------------
>
>                 Key: JBMESSAGING-1316
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1316
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Make sure final fields and properties are used where appropriate.
> Also static inner classes are used, and fields made private.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:39 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1315) Implement
 client "freeze" test
In-Reply-To: <10914498.1211904649509.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1073052205.1248449919839.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1315:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Implement client "freeze" test
> ------------------------------
>
>                 Key: JBMESSAGING-1315
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1315
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Implement a test which freezes (hangs) a client, and makes sure the server disconnects it without the server freezing or delivery getting blocked.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:40 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1194) Support
 quorum for mitigating split brain
In-Reply-To: <21675614.1197367312287.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1734941471.1248449920014.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1194:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Support quorum for mitigating split brain
> -----------------------------------------
>
>                 Key: JBMESSAGING-1194
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1194
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:40 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1149) Singleton
 consumer on queue/topic
In-Reply-To: <15322200.1194961485037.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1240791928.1248449920198.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1149:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Singleton consumer on queue/topic
> ---------------------------------
>
>                 Key: JBMESSAGING-1149
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1149
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.4.0.SP1
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> A last minute requirement came up from the AS team (Carlo and Bill DeCoste).
> JBoss MQ uses HA singleton to provide a singleton consumer on a queue/topic. If that node fails, the consumer should failover onto another single node.
> Currently this isn't supported in JBM.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:40 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1090) Add
 appropriate Exception handling when hitting MaxSize
In-Reply-To: <9488820.1191326763359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <591637858.1248449920378.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1090:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Add appropriate Exception handling when hitting MaxSize
> -------------------------------------------------------
>
>                 Key: JBMESSAGING-1090
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1090
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Messaging Core
>    Affects Versions: 1.4.0.GA
>            Reporter: Jay Howell
>            Assignee: Tim Fox
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> When using MaxSize for a queue and topic the following behaviors exist
> Queue - When a queue hits MaxSize, the delivery returned in Channel Support is null.  This triggers a very generic JMSException to be thrown by looking at the delivery and seeing if it's null in the ServerConnectionEndpoint.
> Topic - When a subscription hits the MaxSize(defined in the topic), the delivery returned will be null, but no check is done and no JMSException is thrown in the ServerConnectionEndpoint.
> What this means is that anyone who wants to put hooks in to gather the messages dropped can't.  Either because the exception is too generic or because one is not thrown at all.
> I would purpose that we put proper exception handling down in the ChannelSupport where MaxSize is checked for both queues and subscriptions.  
> We would need to Change the The two methods in channel support for send and sendInternal to throw a JMSException.  Then we throw a checked Exception in ChannelSupport for MaxSize violations(make a new exception derived from MessagingJMSException).  
> Adding proper exception handling to these would allow users to add aspects and notifications when messages are dropped due to MaxSize.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:40 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-753) Distribute ant
 with the distro
In-Reply-To: <31300965.1169039633086.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1741982130.1248449920518.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-753:
----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Distribute ant with the distro
> ------------------------------
>
>                 Key: JBMESSAGING-753
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-753
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Build System
>            Reporter: Galder Zamarreno
>            Assignee: Tim Fox
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> Add to source and make messaging add it to the binary distribution 
> under util directory. That should speed up patching AS for customers 
> and would guarantee that they use the Ant version that we want them to use.
> This is currently implemented in JBC and JGroups and I find it very useful.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:37 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1400) Allow users
 to configure a system wide maximum connection limit
In-Reply-To: <8050340.1216224002198.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <98774192.1248449917279.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1400:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Allow users to configure a system wide maximum connection limit
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1400
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1400
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Jay Howell
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Many users are complaining of errors that say "Too many open files", which comes from the number of sockets open during jms processing. It's currently possible to run the system out of resources.  We currently only have control of this through the remoting/netty/mina layer.  We should have a setting in JBM that limits the number of connections systemwide, that is independent of the remoting protocol/package.  This way users wouldn't have to keep learning a new package/configuration setting each time the communications package changes in jbm.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:37 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1399) Allow users
 to configure a system wide maximum session limit
In-Reply-To: <4175115.1216223127220.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <676139401.1248449917409.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1399:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Allow users to configure a system wide maximum session limit
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1399
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1399
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>            Reporter: Jay Howell
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> Goal: keep external/internal clients from running the system out of resources(threads/memory).
> We currently have a problem where there is no limit to the number of sessions that can be created in the system.  It would be theoretically possible to have an external client create 1 million sessions in one connection and run the sever out of resources.   It's also possible to set the number of max sessions for an mdb high enough to run the system out of resources(threads/memory).  We need to be able to set a limit for the number of sessions for the system. 
> I've looked at other Messaging systems, like IBM MQ and it seems that other systems have the same setting. 
> We've had users naively suggest that we could implement this by using a bounded thread pool.  This seems too intrusive and too dangerous to do.  This can be done by limiting the number of sessions in the system, which seems like a much better suggestion.  This is much better than using a bounded thread pool for many reasons.  A couple of the reasons is..
> 1.  It doesn't expose the internal workings of JBM to the management console(leaky abstraction).  
> 2.  Users can understand a session limit easier than having to understand the internal thread pool implementation.
> 3.  Doesn't incur deadlocks
> 4.  Allows All clients to get back a message that says some thing like "Session limit reached".
> JBM 2.0 uses an unbounded thread pool for threads, which addresses any concern any performance difficulties with creating and destroying threads.  So now we can address the max number of threads in the system by configuring max sessions in the system.
> Setting a session limit seems to be a more reasonable approach than the bounded thread pool

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:37 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1375) Validate if
 the journal directory is ext3 or ext2
In-Reply-To: <17094750.1213643913298.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <840268036.1248449917537.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1375:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Validate if the journal directory is ext3 or ext2
> -------------------------------------------------
>
>                 Key: JBMESSAGING-1375
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1375
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0 Alpha
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> If the journal dir is anything different than ext2 or ext3, we should use NIO instead.
> This includes SMB or Network mount points.
> a SAN should work fine as long as you use ext2 or 3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:40 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-390)
 ConnectionFactory and JBossDestination should be Referenceable
Message-ID: <1966462748.1248449920660.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-390:
----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> ConnectionFactory and JBossDestination should be Referenceable
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-390
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-390
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> as per spec 4.2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:40 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-377) Competing
 consumer on subscriptions
Message-ID: <1761037278.1248449920765.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-377:
----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Competing consumer on subscriptions
> -----------------------------------
>
>                 Key: JBMESSAGING-377
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-377
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Minor
>             Fix For: 2.0.0
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> We should add an ability to have competing consumers on (durable) subscriptions. This will allow us to load balance processing of messages from a durable subscription across multiple consumers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:40 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-375) Grouping of
	messages
Message-ID: <1145940547.1248449920958.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-375:
----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Grouping of messages
> --------------------
>
>                 Key: JBMESSAGING-375
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-375
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Tim Fox
>            Assignee: Andy Taylor
>             Fix For: 2.0.0
>
>         Attachments: jbmessaging-375.patch, patch-JBMESSAGING-375.txt, patch-JBMESSAGING-375.txt
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> We should add an ability to group messages by a group id so any messages with the same group id always go to the same consumer on a queue.
> This would be useful when having competing consumers on a queue and you want each consumer to handle all messages with a particular value of group id.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:41 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-357) Update design
	documentation
Message-ID: <1162780442.1248449921108.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-357:
----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Update design documentation
> ---------------------------
>
>                 Key: JBMESSAGING-357
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-357
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Documentation and Training
>            Reporter: Ovidiu Feodorov
>             Fix For: 2.0.0
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Make sure design documentation for JBM 2 exists and is up to date.
> All areas of design should be documentated.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:41 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-211) Destination
 programmatic deployment example/integration test
Message-ID: <1173673275.1248449921280.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-211:
----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Destination programmatic deployment example/integration test
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-211
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-211
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>            Priority: Optional
>             Fix For: 2.0.0
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Write the corresponing docs/example/programmatic-deployment integration test.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:41 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-152) Refactor
	exception handling
Message-ID: <1177390210.1248449921455.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-152:
----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Refactor exception handling
> ---------------------------
>
>                 Key: JBMESSAGING-152
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-152
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: JMS Facade
>            Reporter: Tim Fox
>            Assignee: Tim Fox
>            Priority: Minor
>             Fix For: 2.0.0
>
>   Original Estimate: 1 day, 4 hours
>  Remaining Estimate: 1 day, 4 hours
>
> We should audit the exception handling.
> In some areas it is quite sloppy including anti-patterns such as:
> 1. Logging errors when they're not being handled
> 2. Rethrowing with less information. E.g. losing the message or original exception.
> 3. Too much usage of "throws Throwable" or "throws Exception" where probably unnecessary.
> 4. Swallowing exceptions.
> We need to go through the whole of the code, auditing and changing as necessary.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:35 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1550) Core
 BridgeConfiguration with a discovery group is not deployed
In-Reply-To: <22813655.1237480462871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1647486600.1248449915906.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1550:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Core BridgeConfiguration with a discovery group is not deployed
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1550
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1550
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Jeff Mesnil
>            Assignee: Tim Fox
>             Fix For: 2.0.0
>
>
> A Core BridgeConfiguration can be set with either a discovery group or a pair of connectors.
> When the bridge is deployed (in ClusterManager.start()), we only check for the pair of connectors.
> If the bridge config uses a discovery group, it will never be deployed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:38:35 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1542) Add more
 failover tests for paging
In-Reply-To: <5860634.1236203362692.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <461833121.1248449915994.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1542:
-----------------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.0.0.beta4)


> Add more failover tests for paging
> ----------------------------------
>
>                 Key: JBMESSAGING-1542
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1542
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:42:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-1504) Full Journal
	Compactation
In-Reply-To: <33137475.1234453664451.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <618182898.1248450149547.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic reopened JBMESSAGING-1504:
------------------------------------------



> Full Journal Compactation
> -------------------------
>
>                 Key: JBMESSAGING-1504
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1504
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>            Priority: Critical
>             Fix For: 2.0.0.beta4
>
>
> Let me describe how I think the compacting should work.
> Let's say we have a set of files in the journal:
> F0, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10
> min files is set to 10
> The current file is F6 and F7, F8, F9, F10 are unused files waiting to be used
> F0, F1, F2, F3, F4, F5 are files full of data and not open any more, however, data about their contents are stored in memory.
> We need a compacting thread that intermittently (say every 30 seconds) scans the set of journal files in memory.
> It scans F0... F5, and when it has completed that scan, it can decide which records are no longer needed in each file.
> A record is no longer needed in a file if it has already been deleted in any file F0.. F5.
> Once the scanner thread has computed which records are needed and which are not, it can compute a percentage of which records in total are dead space.
> E.g. the scanner might compute that 72% of the data in files F0.. .F5 are dead space.
> We then have a parameter that the user can configure compactorDeadSpaceThresholdPercentage, e.g. this might have a default of 75%.
> If the amount of dead space computed by the scanner >= compactorDeadSpaceThresholdPercentage, then the scanner will compact those files.
> The actual compacting approach goes as follows:
> The scanner knows how many new files it will need for the compacted records, let's say it needs two new files - it can get these from the unused files (e.g. F7, F8, F9 or F10) if they are available.
> It then opens the old files F0..F5 loads the wanted records into memory in blocks and copies them to the new files.
> When this process is finished it will end up with, say, two new files containing the compacted records.
> We can then save a marker file (empty in the journal directory) which says we are starting the rename.
> The old files F0..F5 then need to be renamed so they are no longer used by the journal (but can be recovered in case of a crash).
> Then the two new files need to be renamed so they will be picked up by the journal.
> When that process completes the marker file can be deleted.
> If the server crashes after renaming the old files but before renaming the new files, then the marker file will still exist in the journal. The journal can detect this on startup, and finish the process.
> This ensures the journal will still startup after such a crash.
> Also the JournalFile objects also need to be updated in memory when the compact is complete.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:42:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1504) Full Journal
	Compactation
In-Reply-To: <33137475.1234453664451.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2013384667.1248450149727.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1504:
-----------------------------------------

    Issue Type: Feature Request  (was: Task)


> Full Journal Compactation
> -------------------------
>
>                 Key: JBMESSAGING-1504
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1504
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>            Priority: Critical
>             Fix For: 2.0.0.beta4
>
>
> Let me describe how I think the compacting should work.
> Let's say we have a set of files in the journal:
> F0, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10
> min files is set to 10
> The current file is F6 and F7, F8, F9, F10 are unused files waiting to be used
> F0, F1, F2, F3, F4, F5 are files full of data and not open any more, however, data about their contents are stored in memory.
> We need a compacting thread that intermittently (say every 30 seconds) scans the set of journal files in memory.
> It scans F0... F5, and when it has completed that scan, it can decide which records are no longer needed in each file.
> A record is no longer needed in a file if it has already been deleted in any file F0.. F5.
> Once the scanner thread has computed which records are needed and which are not, it can compute a percentage of which records in total are dead space.
> E.g. the scanner might compute that 72% of the data in files F0.. .F5 are dead space.
> We then have a parameter that the user can configure compactorDeadSpaceThresholdPercentage, e.g. this might have a default of 75%.
> If the amount of dead space computed by the scanner >= compactorDeadSpaceThresholdPercentage, then the scanner will compact those files.
> The actual compacting approach goes as follows:
> The scanner knows how many new files it will need for the compacted records, let's say it needs two new files - it can get these from the unused files (e.g. F7, F8, F9 or F10) if they are available.
> It then opens the old files F0..F5 loads the wanted records into memory in blocks and copies them to the new files.
> When this process is finished it will end up with, say, two new files containing the compacted records.
> We can then save a marker file (empty in the journal directory) which says we are starting the rename.
> The old files F0..F5 then need to be renamed so they are no longer used by the journal (but can be recovered in case of a crash).
> Then the two new files need to be renamed so they will be picked up by the journal.
> When that process completes the marker file can be deleted.
> If the server crashes after renaming the old files but before renaming the new files, then the marker file will still exist in the journal. The journal can detect this on startup, and finish the process.
> This ensures the journal will still startup after such a crash.
> Also the JournalFile objects also need to be updated in memory when the compact is complete.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:42:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1504) Full Journal
	Compactation
In-Reply-To: <33137475.1234453664451.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1489464161.1248450149958.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1504.
----------------------------------------

    Resolution: Done


> Full Journal Compactation
> -------------------------
>
>                 Key: JBMESSAGING-1504
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1504
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>            Priority: Critical
>             Fix For: 2.0.0.beta4
>
>
> Let me describe how I think the compacting should work.
> Let's say we have a set of files in the journal:
> F0, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10
> min files is set to 10
> The current file is F6 and F7, F8, F9, F10 are unused files waiting to be used
> F0, F1, F2, F3, F4, F5 are files full of data and not open any more, however, data about their contents are stored in memory.
> We need a compacting thread that intermittently (say every 30 seconds) scans the set of journal files in memory.
> It scans F0... F5, and when it has completed that scan, it can decide which records are no longer needed in each file.
> A record is no longer needed in a file if it has already been deleted in any file F0.. F5.
> Once the scanner thread has computed which records are needed and which are not, it can compute a percentage of which records in total are dead space.
> E.g. the scanner might compute that 72% of the data in files F0.. .F5 are dead space.
> We then have a parameter that the user can configure compactorDeadSpaceThresholdPercentage, e.g. this might have a default of 75%.
> If the amount of dead space computed by the scanner >= compactorDeadSpaceThresholdPercentage, then the scanner will compact those files.
> The actual compacting approach goes as follows:
> The scanner knows how many new files it will need for the compacted records, let's say it needs two new files - it can get these from the unused files (e.g. F7, F8, F9 or F10) if they are available.
> It then opens the old files F0..F5 loads the wanted records into memory in blocks and copies them to the new files.
> When this process is finished it will end up with, say, two new files containing the compacted records.
> We can then save a marker file (empty in the journal directory) which says we are starting the rename.
> The old files F0..F5 then need to be renamed so they are no longer used by the journal (but can be recovered in case of a crash).
> Then the two new files need to be renamed so they will be picked up by the journal.
> When that process completes the marker file can be deleted.
> If the server crashes after renaming the old files but before renaming the new files, then the marker file will still exist in the journal. The journal can detect this on startup, and finish the process.
> This ensures the journal will still startup after such a crash.
> Also the JournalFile objects also need to be updated in memory when the compact is complete.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:49:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 24 Jul 2009 11:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1427) Journal
	Cleanup
In-Reply-To: <6551971.1222785211162.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <487105437.1248450569266.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1427:
-----------------------------------------

    Issue Type: Feature Request  (was: Task)


> Journal Cleanup
> ---------------
>
>                 Key: JBMESSAGING-1427
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1427
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0 Alpha
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> If a destination is lazy, not consuming messages for a long time, the journal will grow until those messages are consumed.
> This would be a problem with DLQs or messages taking days before they are consumed.
> Since we inform the TransactionSummary on commits, we could change the journal to support multiple current-files based on configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:59:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 24 Jul 2009 11:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1877) Track the
 upgrades during EJB3 plugin 1.0.12 release
Message-ID: <515965219.1248451169196.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Track the upgrades during EJB3 plugin 1.0.12 release
----------------------------------------------------

                 Key: EJBTHREE-1877
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1877
             Project: EJB 3.0
          Issue Type: Task
          Components: plugin
            Reporter: jaikiran pai


Track changes during EJB3 plugin 1.0.12 release

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 11:59:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 24 Jul 2009 11:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1877) Track the
 upgrades during EJB3 plugin 1.0.12 release
In-Reply-To: <515965219.1248451169196.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <555166385.1248451169264.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned EJBTHREE-1877:
--------------------------------------

    Assignee: jaikiran pai


> Track the upgrades during EJB3 plugin 1.0.12 release
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1877
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1877
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: plugin
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> Track changes during EJB3 plugin 1.0.12 release

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 13:14:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Jul 2009 13:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7122) Handling of system
 properties in org.jboss.Main is inconsistent
Message-ID: <2048887591.1248455669283.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Handling of system properties in org.jboss.Main is inconsistent
---------------------------------------------------------------

                 Key: JBAS-7122
                 URL: https://jira.jboss.org/jira/browse/JBAS-7122
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-6.0.0.Alpha1


Main includes a Map<String, String> "props" which is used as a source of configuration information. In the Main constructor, this map is populated from the contents of the system properties. But during processCommandLine() any -D values are not added to the "props" map. Effect is adding something like -Djboss.bind.address=0.0.0.0 to JAVA_OPTS in run.conf works but passing it as a command line argument does not.

This is a minor issue; from the command line just use the command line switch that equates to the system property, e.g. -b 0.0.0.0

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 14:05:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Jul 2009 14:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7119) org.jboss.Main
 doesn't "fix" jgroups.bind_addr or java.rmi.server.hostname passed via
 JAVA_OPTS
In-Reply-To: <671760334.1248301229382.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <504479152.1248458729378.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated JBAS-7119:
-----------------------------------

        Summary: org.jboss.Main doesn't "fix" jgroups.bind_addr or java.rmi.server.hostname passed via JAVA_OPTS  (was: org.jboss.Main doesn't "fix" jgroups.bind_addr passed via JAVA_OPTS)
    Description: The logic to "fix" a jgroups.bind_addr and java.rmi.server.hostname values of 0.0.0.0 is only kicking in if the value is passed as an argument to org.jboss.Main. If the value is specified as part of JAVA_OPTS, it gets passed directly to java and doesn't get fixed.  (was: The logic to "fix" a jgroups.bind_addr value of 0.0.0.0 is only kicking in if the value is passed as an argument to org.jboss.Main. If the value is specified as part of JAVA_OPTS, it gets passed directly to java and doesn't get fixed.)


> org.jboss.Main doesn't "fix" jgroups.bind_addr or java.rmi.server.hostname passed via JAVA_OPTS
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7119
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7119
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The logic to "fix" a jgroups.bind_addr and java.rmi.server.hostname values of 0.0.0.0 is only kicking in if the value is passed as an argument to org.jboss.Main. If the value is specified as part of JAVA_OPTS, it gets passed directly to java and doesn't get fixed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 14:05:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Jul 2009 14:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7119) org.jboss.Main
 doesn't "fix" jgroups.bind_addr or java.rmi.server.hostname passed via
 JAVA_OPTS
In-Reply-To: <671760334.1248301229382.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1341986408.1248458729818.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBAS-7119.
----------------------------------

    Fix Version/s: JBossAS-6.0.0.Alpha1
       Resolution: Done


Fixed by separating out the "property fixing" logic from the loop through the command line arguments.

> org.jboss.Main doesn't "fix" jgroups.bind_addr or java.rmi.server.hostname passed via JAVA_OPTS
> -----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-7119
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7119
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The logic to "fix" a jgroups.bind_addr and java.rmi.server.hostname values of 0.0.0.0 is only kicking in if the value is passed as an argument to org.jboss.Main. If the value is specified as part of JAVA_OPTS, it gets passed directly to java and doesn't get fixed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 14:07:29 2009
From: jira-events at lists.jboss.org (Abdel Dridi (JIRA))
Date: Fri, 24 Jul 2009 14:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1691) JBM2 cluster
 fails under heavy load
Message-ID: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBM2 cluster fails under heavy load
-----------------------------------

                 Key: JBMESSAGING-1691
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Clustering
    Affects Versions: 2.0.0.beta4
         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
            Reporter: Abdel Dridi
            Assignee: Tim Fox
         Attachments: cluster-nodes-config-files.zip

I have a cluster of 2 nodes; A and B:
In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.

I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.

I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.

I faced the following issues:
Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
I also see "failed to accept connection: too many open files".

Let me know if you have any question,
Abdel


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 14:07:29 2009
From: jira-events at lists.jboss.org (Abdel Dridi (JIRA))
Date: Fri, 24 Jul 2009 14:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1691) JBM2 cluster
 fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1785860952.1248458849484.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Abdel Dridi updated JBMESSAGING-1691:
-------------------------------------

    Attachment: cluster-nodes-config-files.zip


config files for both cluster pairs (Live/Backup)

> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Tim Fox
>         Attachments: cluster-nodes-config-files.zip
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 14:09:29 2009
From: jira-events at lists.jboss.org (Abdel Dridi (JIRA))
Date: Fri, 24 Jul 2009 14:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1691) JBM2 cluster
 fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1864003653.1248458969303.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Abdel Dridi updated JBMESSAGING-1691:
-------------------------------------

    Attachment: Jbm2ClusterTest-NodeA.zip


> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Tim Fox
>         Attachments: cluster-nodes-config-files.zip, Jbm2ClusterTest-NodeA.zip, Jbm2ClusterTest-NodeB.zip
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 14:09:29 2009
From: jira-events at lists.jboss.org (Abdel Dridi (JIRA))
Date: Fri, 24 Jul 2009 14:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1691) JBM2 cluster
 fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1522226133.1248458969451.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Abdel Dridi updated JBMESSAGING-1691:
-------------------------------------

    Attachment: Jbm2ClusterTest-NodeB.zip


> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Tim Fox
>         Attachments: cluster-nodes-config-files.zip, Jbm2ClusterTest-NodeA.zip, Jbm2ClusterTest-NodeB.zip
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 14:14:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Jul 2009 14:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6847) JBoss MQ Topic and
 Queues deployed on both the servers in cluster.
In-Reply-To: <9360952.1241044307940.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1780000833.1248459269218.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477473#action_12477473 ] 

Brian Stansberry commented on JBAS-6847:
----------------------------------------

If you still see this with JBoss AS 5.0.0.GA or later, please open a thread in the clustering user forum at http://www.jboss.org/index.html?module=bb&op=viewforum&f=64

> JBoss MQ Topic and Queues deployed on both the servers in cluster.
> ------------------------------------------------------------------
>
>                 Key: JBAS-6847
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6847
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-4.2.2.GA
>         Environment: Server: JBoss AS 4.2.2.
> Components Used: HA Singleton, HA JBoss MQ, EJB 3.0
> JVM: 96GB Virtual Memory, Concurrent Garbage Collection algorithm.
> Cluster: 2 servers connected with TCPPING mechanism.
>            Reporter: Gideon Raj
>            Assignee: Brian Stansberry
>
> When both the servers are up and running, one pause (either cause by a GC or a network glitch) causes server2 to start the HA Singleton object and also bind the JMS Queues and Topics. At this point both the servers are running as primaries.
> (Note regarding the pause: We are monitoring the GC collections using JConsole. Only the ParNew collections have taken place, the ConcurrentMarkSweep collection has not yet taken place).
> After a couple of minutes, both the servers communicate, and server1 reestablishes as the sole primary in the cluster. But the HA Singleton, JMS Queues and Topics created in server2 remains and is not unbound. 
> The sequence of events:
> Log message from server1:
> 2009-04-22 17:16:11,251 org.jgroups.blocks.BasicConnectionTable$Connection._send(BasicConnectionTable.java:443) WARN  [org.jgroups.blocks.ConnectionTable] peer closed connection, trying to re-send msg
> 2009-04-22 17:16:11,252 org.jgroups.blocks.BasicConnectionTable$Connection._send(BasicConnectionTable.java:449) ERROR [org.jgroups.blocks.ConnectionTable] 2nd attempt to send data failed too
> Log message from server2
> 2009-04-22 17:15:42,828 org.jboss.ha.framework.server.HAPartitionImpl.suspect(HAPartitionImpl.java:584) INFO  [org.jboss.ha.framework.interfaces.HAPartition.CUSTOMPartition] Suspected member: server1:7800
> ....
> 2009-04-22 17:15:42,940 org.jboss.ha.framework.server.DistributedReplicantManagerImpl.membershipChanged(DistributedReplicantManagerImpl.java:374) INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.CUSTOMPartition] Dead members: 1 ([server1:1199])
> 2009-04-22 17:15:42,941 org.jboss.ha.framework.server.DistributedReplicantManagerImpl.membershipChanged(DistributedReplicantManagerImpl.java:375) INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.CUSTOMPartition] New Members : 0 ([])
> 2009-04-22 17:15:42,941 org.jboss.ha.framework.server.DistributedReplicantManagerImpl.membershipChanged(DistributedReplicantManagerImpl.java:376) INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.CUSTOMPartition] All Members : 1 ([server2:1199])
> .....
> 2009-04-22 17:16:11,255 org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:668) WARN  [org.jgroups.protocols.pbcast.NAKACK] server2:49665] discarded message from non-member server1:57210, my view is [server2:49665|2] [server2:49665]
> 2009-04-22 17:16:11,259 org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:668) WARN  [org.jgroups.protocols.pbcast.NAKACK] server2:49663] discarded message from non-member server1:57208, my view is [server2:49663|2] [server2:49663]
> .....
> 2009-04-22 17:16:13,877 org.jboss.cache.TreeCache.viewAccepted(TreeCache.java:5687) INFO  [org.jboss.cache.TreeCache] viewAccepted(): [server2:49663|3] [server2:49663, server1:57824]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 15:47:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Jul 2009 15:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-535) Move task
 configuration in server-config.xml into a target
In-Reply-To: <1701874410.1247777909261.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1174815178.1248464849313.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier closed JBBUILD-535.
-----------------------------

    Resolution: Done


Moved the task defs and server configs into a target.

> Move task configuration in server-config.xml into a target
> ----------------------------------------------------------
>
>                 Key: JBBUILD-535
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-535
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the task definitions in server-config.xml are not inside a target.  This means that they can't depend on another target to define their path references.  This should be changed so that everything is done inside targets.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 15:49:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Jul 2009 15:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-531) Remove testsuite
 dependency on libraries.ent
In-Reply-To: <6026725.1243637396349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <253053500.1248464969191.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier closed JBBUILD-531.
-----------------------------

    Resolution: Done


The testsuite no longer uses libraries.ent

> Remove testsuite dependency on libraries.ent
> --------------------------------------------
>
>                 Key: JBBUILD-531
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-531
>             Project: JBoss Build System
>          Issue Type: Sub-task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> Currently the testsuite uses the jars in thirdparty via the file libraries.ent.  Instead the paths in the testsuite should directly reference jars in the local maven repository directory.  This can be done by building the paths with the maven ant tasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 15:51:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Jul 2009 15:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-537) Improved target
	dependency tree
In-Reply-To: <1059955584.1248374669143.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <960017059.1248465089147.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-537:
------------------------------

        Summary: Improved target dependency tree  (was: Use target dependencies instead of antcall to avoid duplicate target invocations)
    Description: 
There are still a lot of tasks that are outside of any target.  Eventually, all tasks should be in targets.

There are a lot of <antcall> in the testsuite.  Each antcall creates a new ant project instance and invokes all the dependencies of the invoked target.  This causes certain initialization targets to be run several times.  Possibly this could be improved using either standard target dependencies, or using something like <runltarget> from the antcontrib tasks.

  was:There are currently a lot of <antcall> in the testsuite.  Each antcall creates a new ant project instance and invokes all the dependencies of the invoked target.  Possibly this could be improved using either standard target dependencies, or using something like <calltarget> from the antcontrib tasks.



> Improved target dependency tree
> -------------------------------
>
>                 Key: JBBUILD-537
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-537
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> There are still a lot of tasks that are outside of any target.  Eventually, all tasks should be in targets.
> There are a lot of <antcall> in the testsuite.  Each antcall creates a new ant project instance and invokes all the dependencies of the invoked target.  This causes certain initialization targets to be run several times.  Possibly this could be improved using either standard target dependencies, or using something like <runltarget> from the antcontrib tasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 15:53:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Jul 2009 15:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-539) Switch dependency
 resolution to use a pom in testsuite instead of in thirdparty.
Message-ID: <198920888.1248465209185.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Switch dependency resolution to use a pom in testsuite instead of in thirdparty.
--------------------------------------------------------------------------------

                 Key: JBBUILD-539
                 URL: https://jira.jboss.org/jira/browse/JBBUILD-539
             Project: JBoss Build System
          Issue Type: Sub-task
            Reporter: Paul Gier
            Assignee: Paul Gier




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 15:57:41 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Jul 2009 15:57:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-540) Review notes from
 testsuite refactoring
Message-ID: <68510224.1248465461370.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Review notes from testsuite refactoring
---------------------------------------

                 Key: JBBUILD-540
                 URL: https://jira.jboss.org/jira/browse/JBBUILD-540
             Project: JBoss Build System
          Issue Type: Task
            Reporter: Paul Gier
            Assignee: Paul Gier
             Fix For: Maven Build - App Server (Phase 3)
         Attachments: dependency_notes.txt

I kept some notes related to dependencies while refactoring the testsuite build.  There are some dependencies that might be removed or improved in some way.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 15:57:41 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Jul 2009 15:57:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-540) Review notes from
 testsuite refactoring
In-Reply-To: <68510224.1248465461370.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <471104938.1248465461466.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-540:
------------------------------

    Attachment: dependency_notes.txt


> Review notes from testsuite refactoring
> ---------------------------------------
>
>                 Key: JBBUILD-540
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-540
>             Project: JBoss Build System
>          Issue Type: Task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>         Attachments: dependency_notes.txt
>
>
> I kept some notes related to dependencies while refactoring the testsuite build.  There are some dependencies that might be removed or improved in some way.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 16:02:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Jul 2009 16:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-539) Switch dependency
 resolution to use a pom in dist or testsuite instead of in thirdparty.
In-Reply-To: <198920888.1248465209185.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <239756829.1248465749115.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-539:
------------------------------

    Summary: Switch dependency resolution to use a pom in dist or testsuite instead of in thirdparty.  (was: Switch dependency resolution to use a pom in testsuite instead of in thirdparty.)


> Switch dependency resolution to use a pom in dist or testsuite instead of in thirdparty.
> ----------------------------------------------------------------------------------------
>
>                 Key: JBBUILD-539
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-539
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 17:00:42 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Fri, 24 Jul 2009 17:00:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-1077) Fix problem in
 CompressingMarshaller
In-Reply-To: <21329107.1230710934327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <620947764.1248469242556.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBREM-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ron Sigal updated JBREM-1077:
-----------------------------

    Fix Version/s: 2.5.2 (Flounder)


> Fix problem in CompressingMarshaller
> ------------------------------------
>
>                 Key: JBREM-1077
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1077
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11
>            Reporter: Ron Sigal
>            Assignee: Ron Sigal
>             Fix For: 2.5.2 (Flounder), 2.2.3.SP1
>
>         Attachments: CompressionInvokerMarshaller.java, CompressionInvokerUnmarshaller.java
>
>
> In org.jboss.remoting.marshal.compress.CompressingMarshaller.write(),
>       gzos.finish();
>       oos.flush();
> should be
>       oos.flush();
>       bos.flush();
>       gzos.flush();
>       gzos.finish();
> as it is on the 2.x branch.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 17:07:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 24 Jul 2009 17:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-539) Switch dependency
 resolution to use poms in dist and testsuite instead of in thirdparty.
In-Reply-To: <198920888.1248465209185.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1280056612.1248469649101.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-539:
------------------------------

    Summary: Switch dependency resolution to use poms in dist and testsuite instead of in thirdparty.  (was: Switch dependency resolution to use a pom in dist or testsuite instead of in thirdparty.)


> Switch dependency resolution to use poms in dist and testsuite instead of in thirdparty.
> ----------------------------------------------------------------------------------------
>
>                 Key: JBBUILD-539
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-539
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 24 21:06:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 24 Jul 2009 21:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1877) Track the
 upgrades during EJB3 plugin 1.0.12 release
In-Reply-To: <515965219.1248451169196.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1539333479.1248483989219.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1877.
------------------------------------

                  Resolution: Done
    Component Fix Version(s): jboss-ejb3-plugin:1.0.12


> Track the upgrades during EJB3 plugin 1.0.12 release
> ----------------------------------------------------
>
>                 Key: EJBTHREE-1877
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1877
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: plugin
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> Track changes during EJB3 plugin 1.0.12 release

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 25 00:15:29 2009
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 25 Jul 2009 00:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7123) JBossCacheManager
 remains open to requests after shutdown
Message-ID: <721981088.1248495329189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBossCacheManager remains open to requests after shutdown
---------------------------------------------------------

                 Key: JBAS-7123
                 URL: https://jira.jboss.org/jira/browse/JBAS-7123
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering, Web (Tomcat) service
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


The work Paul Ferraro did with LockValve ensures that typically application activity cannot reach the clustered session manager after its stop() processing executes, but testing is showing the StandardHostValve can end up causing calls to findSession that end up blowing up with an NPE.  That's the specific issue; in general, the methods in the Manager API need to be hardened to react properly if invoked during/after shutdown.

Solution is to use the same semaphore that LockValve uses, but use it internally -- add tryLock/release calls around the relevant code. Once stop() processing proceeds, tryLock will fail and the methods can react appropriately.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Jul 25 10:51:29 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Sat, 25 Jul 2009 10:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7047) Deployers hide
 exception cause stack
In-Reply-To: <6579847.1245767156834.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1786491922.1248533489480.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pete Muir updated JBAS-7047:
----------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
         Assignee: Ales Justin
         Priority: Critical  (was: Major)


Schedule and assign to Ales, we need this to pass the CDI TCK.

> Deployers hide exception cause stack
> ------------------------------------
>
>                 Key: JBAS-7047
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7047
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Pete Muir
>            Assignee: Ales Justin
>            Priority: Critical
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> Currently the deployers unwrap all deployment exceptions to the root cause, and store in incompleteDeployments. This means we can't check for exception wrapping

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jul 26 07:50:29 2009
From: jira-events at lists.jboss.org (Luca Stancapiano (JIRA))
Date: Sun, 26 Jul 2009 07:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-287) active duration
 field creating a new topic
Message-ID: <344391334.1248609029434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

active duration field creating a new topic
------------------------------------------

                 Key: JBFORUMS-287
                 URL: https://jira.jboss.org/jira/browse/JBFORUMS-287
             Project: JBoss Forums
          Issue Type: Bug
    Affects Versions: 1.2.0 Alpha
         Environment: JBoss Portal 2.7.2 with JBoss AS 4.2.3.GA
            Reporter: Luca Stancapiano
            Assignee: Luca Stancapiano
             Fix For: 1.2.0 Alpha, 1.3.0 Alpha, 1.2.0 GA


when I create a new topic I have an error of conversion. The active duration field is an Integer but it is stored as String because the converter doesn't work right:

org.jboss.portlet.forums.ui.action.converters.PollDurationConverter:

   public Object getAsObject(FacesContext context, UIComponent component, String value) throws ConverterException
    {
        
        if (value==null || value.trim().length()==0)
        {
            return 0;
        }
        else
        {
            try
            {
            	return value;
            }
            catch (NumberFormatException e)
            {
                FacesMessage message = new FacesMessage();
                message.setDetail(JSFUtil.getBundleMessage(Constants.BUNDLE_NAME, ValidatorMessages.POLL_DURATION_MSG));
                message.setSummary(JSFUtil.getBundleMessage(Constants.BUNDLE_NAME, ValidatorMessages.POLL_DURATION_MSG));
                message.setSeverity(FacesMessage.SEVERITY_ERROR);
                throw new ConverterException(message);
            }
        }
    }


It should return return Integer.valueOf(value);

because the result is elaborated by the method setActiveDuration(int intactiveDuration)   of org.jboss.portlet.forums.ui.action.PostAction class


It should to be tested in other versions too

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jul 26 16:13:29 2009
From: jira-events at lists.jboss.org (Flavia Rainone (JIRA))
Date: Sun, 26 Jul 2009 16:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-743) Support annotation
 introduction to interfaces
Message-ID: <524496978.1248639209321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Support annotation introduction to interfaces
---------------------------------------------

                 Key: JBAOP-743
                 URL: https://jira.jboss.org/jira/browse/JBAOP-743
             Project: JBoss AOP
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Flavia Rainone


JBoss AOP should support annotation introductions to interfaces. Currently, annotations can be introduced to classes only.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Jul 26 17:53:29 2009
From: jira-events at lists.jboss.org (Luca Stancapiano (JIRA))
Date: Sun, 26 Jul 2009 17:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-287) active duration
 field creating a new topic
In-Reply-To: <344391334.1248609029434.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1469143657.1248645209126.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBFORUMS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luca Stancapiano resolved JBFORUMS-287.
---------------------------------------

    Resolution: Done


done

> active duration field creating a new topic
> ------------------------------------------
>
>                 Key: JBFORUMS-287
>                 URL: https://jira.jboss.org/jira/browse/JBFORUMS-287
>             Project: JBoss Forums
>          Issue Type: Bug
>    Affects Versions: 1.2.0 Alpha
>         Environment: JBoss Portal 2.7.2 with JBoss AS 4.2.3.GA
>            Reporter: Luca Stancapiano
>            Assignee: Luca Stancapiano
>             Fix For: 1.2.0 Alpha, 1.3.0 Alpha, 1.2.0 GA
>
>
> when I create a new topic I have an error of conversion. The active duration field is an Integer but it is stored as String because the converter doesn't work right:
> org.jboss.portlet.forums.ui.action.converters.PollDurationConverter:
>    public Object getAsObject(FacesContext context, UIComponent component, String value) throws ConverterException
>     {
>         
>         if (value==null || value.trim().length()==0)
>         {
>             return 0;
>         }
>         else
>         {
>             try
>             {
>             	return value;
>             }
>             catch (NumberFormatException e)
>             {
>                 FacesMessage message = new FacesMessage();
>                 message.setDetail(JSFUtil.getBundleMessage(Constants.BUNDLE_NAME, ValidatorMessages.POLL_DURATION_MSG));
>                 message.setSummary(JSFUtil.getBundleMessage(Constants.BUNDLE_NAME, ValidatorMessages.POLL_DURATION_MSG));
>                 message.setSeverity(FacesMessage.SEVERITY_ERROR);
>                 throw new ConverterException(message);
>             }
>         }
>     }
> It should return return Integer.valueOf(value);
> because the result is elaborated by the method setActiveDuration(int intactiveDuration)   of org.jboss.portlet.forums.ui.action.PostAction class
> It should to be tested in other versions too

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 01:19:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 27 Jul 2009 01:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-142) SP Post Form
 Authenticator that can handle signatures
In-Reply-To: <356609847.1248362549083.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1757454054.1248671969380.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-142:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha5
                       (was: IDFED-1.0.0.beta1)


> SP Post Form Authenticator that can handle signatures
> -----------------------------------------------------
>
>                 Key: JBID-142
>                 URL: https://jira.jboss.org/jira/browse/JBID-142
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> Currently we do not have a form authenticator doing POST on the SP end that can handle signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 01:19:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Mon, 27 Jul 2009 01:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-142) SP Post Form
 Authenticator that can handle signatures
In-Reply-To: <356609847.1248362549083.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <335668009.1248671969495.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-142.
------------------------------

    Resolution: Done


> SP Post Form Authenticator that can handle signatures
> -----------------------------------------------------
>
>                 Key: JBID-142
>                 URL: https://jira.jboss.org/jira/browse/JBID-142
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> Currently we do not have a form authenticator doing POST on the SP end that can handle signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 04:01:29 2009
From: jira-events at lists.jboss.org (Max Rydahl Andersen (JIRA))
Date: Mon, 27 Jul 2009 04:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7103) Hot deployment
 woks incorrectly on the EE project without deployment descriptors
In-Reply-To: <1370254810.1247736869351.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1915826911.1248681689399.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477585#action_12477585 ] 

Max Rydahl Andersen commented on JBAS-7103:
-------------------------------------------

This is actually a rather big usability issue ;(

Any chance touching the root directory could be made an alternative option for restarting the module ?

> Hot deployment woks incorrectly on the EE project without deployment descriptors
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-7103
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7103
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: Windows XP SP3 
> JBoss AS: 5.0.1.GA
> Eclipse 3.5: eclipse-jee-galileo-win32.zip 
> JBossTools : 3.0.1.GA JBossTools-ALL-win32-3.0.1.GA-R200905070146-H18.zip 
>            Reporter: Alexander Lengson
>            Assignee: Ales Justin
>
> JBoss AS 5.0.1.GA does not redeploy new EJB written over old one when EJB JAR does not contain deployment descriptors and EJB is deployed as an exploded folder, not single-file archive.
> As discussed in another issue (https://jira.jboss.org/jira/browse/JBIDE-4608), this is because of JBoss AS redeploys EJB if its descriptor is touched. Simple changing .class file is not enough to make JBoss redeploy the EJB, but in the case when there is no deployment descriptor (everything is configured via annotations), nothing may cause redeploy (except full remove and new publish)
> Workaround is to have deployment descriptors in the module.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 05:09:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Mon, 27 Jul 2009 05:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-357) Error while
 validating jPDL file: Problem class was moved from API
In-Reply-To: <985295068.1247498249570.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1161835969.1248685769438.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-357.
---------------------------

    Resolution: Done


The validation is also performed automatically when the file is saved. If more sophisticated (i.e. real background) validation is needed a new issue should be created.

> Error while validating jPDL file: Problem class was moved from API
> ------------------------------------------------------------------
>
>                 Key: GPD-357
>                 URL: https://jira.jboss.org/jira/browse/GPD-357
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM jPDL Designer 4.0.0.GA
>            Reporter: Koen Aers
>            Assignee: Koen Aers
>             Fix For: jBPM jPDL Designer 4.1
>
>
> 1) Fix the dynamic loading problem of the problem class that has moved
> 2) Add automatic validation activation in the background

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 06:16:29 2009
From: jira-events at lists.jboss.org (Alexander Lengson (JIRA))
Date: Mon, 27 Jul 2009 06:16:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBASMP-21) Maven integration
 issues: setting facets on maven projects and deploying ear on JBoss
Message-ID: <895686066.1248689789366.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Maven integration issues: setting facets on maven projects and deploying ear on JBoss
-------------------------------------------------------------------------------------

                 Key: JBASMP-21
                 URL: https://jira.jboss.org/jira/browse/JBASMP-21
             Project: JBoss AS Maven Plugins
          Issue Type: Bug
         Environment: Eclipse 3.5 
m2eclipse (0.9.9.20090720)
JBoss Tools AS M3 developer version
Subclipse SVN plugin 1.6.3
            Reporter: Alexander Lengson
            Assignee: Andrew Lee Rubinger



Using Maven command line, I created four projects:
container - the parent Maven project. It also serves as a container for other projects
prj-jar - a shared library used by all other EJBs
prj-ejb - sample EJB
prj-ear - EE container for jar and ejb

Apache plugins for Maven (both for ejb and ear) are used. 

I've performed the following steps:
* imported container into SVN
* opened Eclipse 3.5 with M3 JBoss AS Tools and dev version of m2eclipse (0.9.9.20090720)
* right-clicked on container and chosen "Checkout as Maven project"
* waited for the process to be finished

And the following likely are bugs and/or open questions:
* for prj-jar: 0.0.1-SNAPSHOT "JBoss Maven Integration" facet is not checked. After checking further configuration suggests "0.0.1-SNAPSHOT" instead of "1.0-SNAPSHOT" as declared in pom.xml already.
* for prj-ejb: the same, i.e. 0.0.1-SNAPSHOT "JBoss Maven Integration" facet is not checked. After checking further configuration suggests "0.0.1-SNAPSHOT" instead of "1.0-SNAPSHOT" as declared in pom.xml already.
* for prj-ear: the same.
* for container: "JBoss Maven Integration" facet is not set and can not be selected. What another facet should be set to meet requirements?
* for prj-ejb: there is no Project Facet checked at all.
* for prj-ejb: when I check EJB 3.0 and then click Further Configuration, it does not propose sensible defaults (instead they are as always: src for sources, build/classes for compiled)
* for prj-ejb: If I provided values for src and build folder mistakenly, it does not allow to change them (even uncheck/check again shows only form with all fields greyed)
* for prj-ejb: after checking Java 6.0 and EJB 3.0, there are still errors in Problems View:
	EJB Module 3.0 requires Java 5.0 or newer.	prj-ejb		line 1	Maven Problem --- disappears after Eclipse restart
	One or more constraints have not been satisfied.	prj-ejb		line 1	Maven Problem --- disappears after Eclipse restart
	Java compiler level does not match the version of the installed Java project facet.	prj-ejb		Unknown	Faceted Project Problem (Java Version Mismatch) --- survives Eclipse restart
* for prj-ear: Java EE module dependencies are not checked (they may be suggested from the pom.xml) 
* for prj-ear: Maven plugin maven-ear-plugin has the option to put all referenced libraries into Lib directory:
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-ear-plugin</artifactId>
				<version>2.3.2</version>
				<configuration>
					<includeLibInApplicationXml>true</includeLibInApplicationXml>
					...
		That builds the EAR which contains lib/ folder inside and all references libs like:
	drools-api-5.0.1.jar
	drools-core-5.0.1.jar
	hsqldb-1.8.0.10.jar
	joda-time-1.6.jar
	mvel2-2.0.10.jar
	prj-jar-1.0-SNAPSHOT.jar

	That can be assured by running command:
	container>mvn install

	Eclipse does not put those libraries into deploy dir while making "Full Publish" which causes server startup errors.
	It's reasonable to copy these libraries onto server when using JBoss Server View and debugging server from Eclipse.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 07:13:29 2009
From: jira-events at lists.jboss.org (Alexander Lengson (JIRA))
Date: Mon, 27 Jul 2009 07:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBASMP-21) Maven integration
 issues: setting facets on maven projects and deploying ear on JBoss
In-Reply-To: <895686066.1248689789366.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1260765567.1248693209213.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBASMP-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Lengson updated JBASMP-21:
------------------------------------

    Attachment: container.zip


container - the parent Maven project. It also serves as a container for other projects
prj-jar - a shared library used by all other EJBs
prj-ejb - sample EJB
prj-ear - EE container for jar and ejb

> Maven integration issues: setting facets on maven projects and deploying ear on JBoss
> -------------------------------------------------------------------------------------
>
>                 Key: JBASMP-21
>                 URL: https://jira.jboss.org/jira/browse/JBASMP-21
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>         Environment: Eclipse 3.5 
> m2eclipse (0.9.9.20090720)
> JBoss Tools AS M3 developer version
> Subclipse SVN plugin 1.6.3
>            Reporter: Alexander Lengson
>            Assignee: Andrew Lee Rubinger
>         Attachments: container.zip
>
>
> Using Maven command line, I created four projects:
> container - the parent Maven project. It also serves as a container for other projects
> prj-jar - a shared library used by all other EJBs
> prj-ejb - sample EJB
> prj-ear - EE container for jar and ejb
> Apache plugins for Maven (both for ejb and ear) are used. 
> I've performed the following steps:
> * imported container into SVN
> * opened Eclipse 3.5 with M3 JBoss AS Tools and dev version of m2eclipse (0.9.9.20090720)
> * right-clicked on container and chosen "Checkout as Maven project"
> * waited for the process to be finished
> And the following likely are bugs and/or open questions:
> * for prj-jar: 0.0.1-SNAPSHOT "JBoss Maven Integration" facet is not checked. After checking further configuration suggests "0.0.1-SNAPSHOT" instead of "1.0-SNAPSHOT" as declared in pom.xml already.
> * for prj-ejb: the same, i.e. 0.0.1-SNAPSHOT "JBoss Maven Integration" facet is not checked. After checking further configuration suggests "0.0.1-SNAPSHOT" instead of "1.0-SNAPSHOT" as declared in pom.xml already.
> * for prj-ear: the same.
> * for container: "JBoss Maven Integration" facet is not set and can not be selected. What another facet should be set to meet requirements?
> * for prj-ejb: there is no Project Facet checked at all.
> * for prj-ejb: when I check EJB 3.0 and then click Further Configuration, it does not propose sensible defaults (instead they are as always: src for sources, build/classes for compiled)
> * for prj-ejb: If I provided values for src and build folder mistakenly, it does not allow to change them (even uncheck/check again shows only form with all fields greyed)
> * for prj-ejb: after checking Java 6.0 and EJB 3.0, there are still errors in Problems View:
> 	EJB Module 3.0 requires Java 5.0 or newer.	prj-ejb		line 1	Maven Problem --- disappears after Eclipse restart
> 	One or more constraints have not been satisfied.	prj-ejb		line 1	Maven Problem --- disappears after Eclipse restart
> 	Java compiler level does not match the version of the installed Java project facet.	prj-ejb		Unknown	Faceted Project Problem (Java Version Mismatch) --- survives Eclipse restart
> * for prj-ear: Java EE module dependencies are not checked (they may be suggested from the pom.xml) 
> * for prj-ear: Maven plugin maven-ear-plugin has the option to put all referenced libraries into Lib directory:
> 				<groupId>org.apache.maven.plugins</groupId>
> 				<artifactId>maven-ear-plugin</artifactId>
> 				<version>2.3.2</version>
> 				<configuration>
> 					<includeLibInApplicationXml>true</includeLibInApplicationXml>
> 					...
> 		That builds the EAR which contains lib/ folder inside and all references libs like:
> 	drools-api-5.0.1.jar
> 	drools-core-5.0.1.jar
> 	hsqldb-1.8.0.10.jar
> 	joda-time-1.6.jar
> 	mvel2-2.0.10.jar
> 	prj-jar-1.0-SNAPSHOT.jar
> 	That can be assured by running command:
> 	container>mvn install
> 	Eclipse does not put those libraries into deploy dir while making "Full Publish" which causes server startup errors.
> 	It's reasonable to copy these libraries onto server when using JBoss Server View and debugging server from Eclipse.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 08:34:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 27 Jul 2009 08:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1011) Release JGroups
	2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <436059512.1248698069454.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477621#action_12477621 ] 

Richard Achmatowicz commented on JGRP-1011:
-------------------------------------------

Uploaded to SourceForge. 
They have changed their web interface and uploading mechanism considerably. You now add release notes by selecting the file in question and right-clicking. 


> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>         Attachments: JGroups_2_6_11_GA_reports.zip
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 08:36:29 2009
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 27 Jul 2009 08:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-1011) Release JGroups 2.6.11
In-Reply-To: <852272550.1247605049229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2049525716.1248698189129.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz closed JGRP-1011.
-------------------------------------

    Resolution: Done


> Release JGroups 2.6.11
> ----------------------
>
>                 Key: JGRP-1011
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1011
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.6.11
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 2.6.11
>
>         Attachments: JGroups_2_6_11_GA_reports.zip
>
>
> This release is required for EAP 5.0  Beta testing. It may be that during the EAP testing cycle, further fixes will be required to JGroups.
> Here are the fixes which are so far logged against this release:
> Release Notes - JGroups - Version 2.6.11
> ** Bug
>    * [JGRP-912] - Failed to parse the jgroups.xml file
>    * [JGRP-984] - JGroups can not parse IPV6 literals in TCPPING protocol configuration
>    * [JGRP-985] - Flush and join problems during constant node failures and constant joins
>    * [JGRP-986] - FLUSH: relax event sequencing for a joining member
>    * [JGRP-997] - AUTH: incorrect matching of src against memberList
>    * [JGRP-1000] - COMPRESS corrupts some messages
>    * [JGRP-1006] - Shared transport: shunned multiple channels can not reconnect
> ** Task
>    * [JGRP-982] - Extend linux method of creating multicast socket to HP-UX
>    * [JGRP-1004] - GroupRequest: don't ignore InterruptedException
> Over and above these issues, this release needs to be throughly tested against IPv6 and this will require changes to the testsuite, as were applied to 2.4.6 (JGRP-951).
>  
> There are other IPv6-related issues which also should be addressed, in particular JGRP-956.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 09:13:29 2009
From: jira-events at lists.jboss.org (Max Rydahl Andersen (JIRA))
Date: Mon, 27 Jul 2009 09:13:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-534) Maven repository
	aggregation
In-Reply-To: <1192295848.1247639309938.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1108920619.1248700409664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477624#action_12477624 ] 

Max Rydahl Andersen commented on JBBUILD-534:
---------------------------------------------

"* the transitive enclosure of information for (groupId+artifactId+version+classifier) should be equal independent of the repo where you get the artifact from "

unfortunately that does not fit well with the current business model of a split....something gotta give...any suggestions ?

> Maven repository aggregation
> ----------------------------
>
>                 Key: JBBUILD-534
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-534
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Thomas Diesler
>
> There are a number of projects which have dependencies on non-jboss
> maven repos (jboss-osgi is one of them)
> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235779#4235779
> I believe, this issue is general enough to have proper repo aggregation 
> setup somehow
> Here is a link to some aggregators
> http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix
> Is this a way you want to move forward or should we stick with manually copying individual artefacts to the jboss repo? 
> Please note, that by doing so (i.e. mvn deploy-file) you loose the original pom and hence the information on transitive dependencies.
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 09:26:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Mon, 27 Jul 2009 09:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-534) Maven repository
	aggregation
In-Reply-To: <1192295848.1247639309938.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1564709938.1248701189295.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477628#action_12477628 ] 

Paul Gier commented on JBBUILD-534:
-----------------------------------

There was some discussion on the maven developers list about repository synching, and how we can manage synchronization with our dependencies on rebuilt stuff (for example all the jars with "-brew" at the end).  We can't send them to the central repository because they are not our upstream projects, but we need them for building projects like the app server.  So it doesn't really do us any good to synchronize the jboss app server jars to central if we can't also send the dependencies.  So the recommendation is to change the groupId of our rebuilt artifacts and prefix it with something like "org.jboss".  If we use a groupId like this then we could avoid conflicts caused by rebuilt artifacts.  But this would cause other problems [1].

[1]http://www.nabble.com/Depending-on-Artifacts-not-in-central-td24394458.html

> Maven repository aggregation
> ----------------------------
>
>                 Key: JBBUILD-534
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-534
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Thomas Diesler
>
> There are a number of projects which have dependencies on non-jboss
> maven repos (jboss-osgi is one of them)
> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235779#4235779
> I believe, this issue is general enough to have proper repo aggregation 
> setup somehow
> Here is a link to some aggregators
> http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix
> Is this a way you want to move forward or should we stick with manually copying individual artefacts to the jboss repo? 
> Please note, that by doing so (i.e. mvn deploy-file) you loose the original pom and hence the information on transitive dependencies.
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 09:46:29 2009
From: jira-events at lists.jboss.org (Max Rydahl Andersen (JIRA))
Date: Mon, 27 Jul 2009 09:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-534) Maven repository
	aggregation
In-Reply-To: <1192295848.1247639309938.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <698373512.1248702389526.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477639#action_12477639 ] 

Max Rydahl Andersen commented on JBBUILD-534:
---------------------------------------------

yes - exactly, its not really solvable if product binaries are considered different.
Then the dependency set will have to be different for both project and product builds which will lead to horrible maintanence headache ;(

> Maven repository aggregation
> ----------------------------
>
>                 Key: JBBUILD-534
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-534
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Thomas Diesler
>
> There are a number of projects which have dependencies on non-jboss
> maven repos (jboss-osgi is one of them)
> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235779#4235779
> I believe, this issue is general enough to have proper repo aggregation 
> setup somehow
> Here is a link to some aggregators
> http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix
> Is this a way you want to move forward or should we stick with manually copying individual artefacts to the jboss repo? 
> Please note, that by doing so (i.e. mvn deploy-file) you loose the original pom and hence the information on transitive dependencies.
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 10:49:40 2009
From: jira-events at lists.jboss.org (Juergen none (JIRA))
Date: Mon, 27 Jul 2009 10:49:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7124)
 org.jboss.security.ssl.DomainSocketFactory to override zero-argument
 javax.net.SocketFactory.createSocket()
Message-ID: <1257933592.1248706180664.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

org.jboss.security.ssl.DomainSocketFactory to override zero-argument javax.net.SocketFactory.createSocket()
-----------------------------------------------------------------------------------------------------------

                 Key: JBAS-7124
                 URL: https://jira.jboss.org/jira/browse/JBAS-7124
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Juergen none
            Assignee: Anil Saldhana


I use org.jboss.security.ssl.DomainSocketFactory but need to call parameterless createSocket()

this method is not overridden in DomainSocketFactory, so initSSLContext(), setNeedClientAuth(), etc. does not happen.

could you implement org.jboss.security.ssl.DomainSocketFactory.createSocket() ?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 11:14:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 27 Jul 2009 11:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1692)
 symmetric-cluster example fails on a multi-core machine
Message-ID: <1737804129.1248707669208.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

symmetric-cluster example fails on a multi-core machine
-------------------------------------------------------

                 Key: JBMESSAGING-1692
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1692
             Project: JBoss Messaging
          Issue Type: Task
    Affects Versions: 2.0.0.beta4, 2.0.0.beta3, 2.0.0.beta2
            Reporter: Clebert Suconic
            Assignee: Tim Fox
             Fix For: 2.0.0




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 11:44:41 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Mon, 27 Jul 2009 11:44:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-537) Improved Ant
 target dependency hierarchy for building
In-Reply-To: <1059955584.1248374669143.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2102610349.1248709481790.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-537:
------------------------------

    Summary: Improved Ant target dependency hierarchy for building  (was: Improved target dependency tree)


> Improved Ant target dependency hierarchy for building
> -----------------------------------------------------
>
>                 Key: JBBUILD-537
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-537
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> There are still a lot of tasks that are outside of any target.  Eventually, all tasks should be in targets.
> There are a lot of <antcall> in the testsuite.  Each antcall creates a new ant project instance and invokes all the dependencies of the invoked target.  This causes certain initialization targets to be run several times.  Possibly this could be improved using either standard target dependencies, or using something like <runltarget> from the antcontrib tasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 11:46:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Mon, 27 Jul 2009 11:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-540) Review notes from
 testsuite refactoring
In-Reply-To: <68510224.1248465461370.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <258224337.1248709589279.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-540:
------------------------------

        Parent: JBBUILD-529
    Issue Type: Sub-task  (was: Task)


> Review notes from testsuite refactoring
> ---------------------------------------
>
>                 Key: JBBUILD-540
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-540
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>         Attachments: dependency_notes.txt
>
>
> I kept some notes related to dependencies while refactoring the testsuite build.  There are some dependencies that might be removed or improved in some way.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 11:46:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Mon, 27 Jul 2009 11:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-540) Review dependency
 notes from testsuite refactoring and clean up AS dependency tree
In-Reply-To: <68510224.1248465461370.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1570463911.1248709589326.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-540:
------------------------------

        Summary: Review dependency notes from testsuite refactoring and clean up AS dependency tree  (was: Review notes from testsuite refactoring)
    Description: I am keeping notes related to dependencies while refactoring the testsuite build.  There are some dependencies that might be removed or reorganized in a better way.  (was: I kept some notes related to dependencies while refactoring the testsuite build.  There are some dependencies that might be removed or improved in some way.)


> Review dependency notes from testsuite refactoring and clean up AS dependency tree
> ----------------------------------------------------------------------------------
>
>                 Key: JBBUILD-540
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-540
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>         Attachments: dependency_notes.txt
>
>
> I am keeping notes related to dependencies while refactoring the testsuite build.  There are some dependencies that might be removed or reorganized in a better way.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 11:52:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 27 Jul 2009 11:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBAS-7125) JMS Destinations:
 properties "Count" and "Time Last Update" are 0 after sending a message
Message-ID: <303504614.1248709949471.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer moved EMBJOPR-206 to JBAS-7125:
--------------------------------------------

     Project: JBoss Application Server  (was: Embedded Jopr)
         Key: JBAS-7125  (was: EMBJOPR-206)
    Security: Public


> JMS Destinations: properties "Count" and "Time Last Update" are 0 after sending a message
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-7125
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7125
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Tests:
> testQueueMetrics*
> testTopicMetrics*
>            Reporter: Ondrej ?i?ka
>
> After sending a message(s), the some properties have bad values:
> Count = 0,
> Count Delta = 0,
> Time Last Update = 0,
> However, 
> Depth	4	The current message count of pending messages within the queue waiting for dispatch
> Depth Delta	3	The message count delta of pending messages since last method call
> Did the meaning of  Count change?
> I've looked at the queue MBean in JMX console, and there's no count property. Jopr takes this from ProfilseService, so perhaps that's where zero comes from? Anyway, this is a regression.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jul 27 11:54:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 27 Jul 2009 11:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7125) JMS Destinations:
 properties "Count" and "Time Last Update" are 0 after sending a message
Message-ID: <925954164.1248710069234.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7125:
-------------------------------

          Component/s: JMS (JBoss Messaging)
                       ProfileService
        Fix Version/s: JBossAS-5.2.0.Beta1
    Affects Version/s: JBossAS-5.1.0.GA
             Assignee: Scott M Stark


Scott, this one sounds like either a JBoss Messaging, or a PS MO, bug. Would you take a look?


> JMS Destinations: properties "Count" and "Time Last Update" are 0 after sending a message
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-7125
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7125
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging), ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Tests:
> testQueueMetrics*
> testTopicMetrics*
>            Reporter: Ondrej ?i?ka
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> After sending a message(s), the some properties have bad values:
> Count = 0,
> Count Delta = 0,
> Time Last Update = 0,
> However, 
> Depth	4	The current message count of pending messages within the queue waiting for dispatch
> Depth Delta	3	The message count delta of pending messages since last method call
> Did the meaning of  Count change?
> I've looked at the queue MBean in JMX console, and there's no count property. Jopr takes this from ProfilseService, so perhaps that's where zero comes from? Anyway, this is a regression.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jul 27 11:54:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Mon, 27 Jul 2009 11:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7125) JMS Destinations:
 properties "Count" and "Time Last Update" are 0 after sending a message
Message-ID: <1354613486.1248710069330.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer updated JBAS-7125:
-------------------------------

    Labels: EmbJopr1_3 ManagedObject  (was: )


> JMS Destinations: properties "Count" and "Time Last Update" are 0 after sending a message
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-7125
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7125
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging), ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Tests:
> testQueueMetrics*
> testTopicMetrics*
>            Reporter: Ondrej ?i?ka
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> After sending a message(s), the some properties have bad values:
> Count = 0,
> Count Delta = 0,
> Time Last Update = 0,
> However, 
> Depth	4	The current message count of pending messages within the queue waiting for dispatch
> Depth Delta	3	The message count delta of pending messages since last method call
> Did the meaning of  Count change?
> I've looked at the queue MBean in JMX console, and there's no count property. Jopr takes this from ProfilseService, so perhaps that's where zero comes from? Anyway, this is a regression.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Jul 27 14:01:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-119) Hibernate Validator
	4.0.0.Beta2
In-Reply-To: <1098713284.1247792429189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1742292896.1248717689419.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-119:
----------------------------------

    Summary: Hibernate Validator 4.0.0.Beta2  (was: Hibernate Validator 4.0.0Beta2)


> Hibernate Validator 4.0.0.Beta2
> -------------------------------
>
>                 Key: JBJCA-119
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-119
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> for 303 requirement 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 14:03:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-120) Validation API
	1.0.CR3
In-Reply-To: <105271748.1248261929139.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <993979413.1248717809523.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-120:
----------------------------------

    Summary: Validation API 1.0.CR3  (was: javax validation-api 1.0.CR3)


> Validation API 1.0.CR3
> ----------------------
>
>                 Key: JBJCA-120
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-120
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 14:03:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-121) SLF4J 1.5.6
Message-ID: <490362193.1248717809672.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SLF4J 1.5.6
-----------

                 Key: JBJCA-121
                 URL: https://jira.jboss.org/jira/browse/JBJCA-121
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 14:03:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-122) JBoss LogManager
	1.1.0.CR4
Message-ID: <563107268.1248717809750.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss LogManager 1.1.0.CR4
--------------------------

                 Key: JBJCA-122
                 URL: https://jira.jboss.org/jira/browse/JBJCA-122
             Project: JBoss JCA
          Issue Type: Component Upgrade
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 14:07:42 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:07:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-123) Update logging
	framework
Message-ID: <1781074719.1248718062317.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Update logging framework
------------------------

                 Key: JBJCA-123
                 URL: https://jira.jboss.org/jira/browse/JBJCA-123
             Project: JBoss JCA
          Issue Type: Task
          Components: Build, Standalone
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Update the logging framework to use JBoss LogManager 1.1 and dependant libraries.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 14:15:30 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Mon, 27 Jul 2009 14:15:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7112) EJB3 Metrics Test
 Failing in trunk
In-Reply-To: <1445531349.1248129869264.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1458178918.1248718530079.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBAS-7112.
---------------------------------------

    Resolution: Done


> EJB3 Metrics Test Failing in trunk
> ----------------------------------
>
>                 Key: JBAS-7112
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7112
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> Managed Component not getting deployed?
> junit.framework.AssertionFailedError: Component not found; no managed object with name "testEjb3xMetrics.jar/TestLoggingMDB" in: []
> 	at org.jboss.test.profileservice.test.Ejb3MetricsUnitTestCase.getAndTestManagedComponent(Ejb3MetricsUnitTestCase.java:416)
> 	at org.jboss.test.profileservice.test.Ejb3MetricsUnitTestCase.testMdb(Ejb3MetricsUnitTestCase.java:319)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 14:21:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-124) Remove AOP stack
 from MC configuration
Message-ID: <1533957505.1248718889309.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Remove AOP stack from MC configuration
--------------------------------------

                 Key: JBJCA-124
                 URL: https://jira.jboss.org/jira/browse/JBJCA-124
             Project: JBoss JCA
          Issue Type: Task
          Components: Build, Standalone
    Affects Versions: 1.0.0.Alpha2
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen


Remove the AOP stack from the JBoss Microcontainer configuration, since no deployments actually needs it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 14:25:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-124) Remove AOP stack
 from MC configuration
In-Reply-To: <1533957505.1248718889309.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <472747515.1248719129335.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-124.
-----------------------------------

    Resolution: Done


> Remove AOP stack from MC configuration
> --------------------------------------
>
>                 Key: JBJCA-124
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-124
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Build, Standalone
>    Affects Versions: 1.0.0.Alpha2
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>
> Remove the AOP stack from the JBoss Microcontainer configuration, since no deployments actually needs it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 14:41:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-125) JBoss Classloading
	2.0.6.GA
Message-ID: <827060506.1248720089293.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss Classloading 2.0.6.GA
---------------------------

                 Key: JBJCA-125
                 URL: https://jira.jboss.org/jira/browse/JBJCA-125
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 14:41:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-126) JBoss Deployer
	2.0.8.GA
Message-ID: <290360875.1248720089360.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss Deployer 2.0.8.GA
-----------------------

                 Key: JBJCA-126
                 URL: https://jira.jboss.org/jira/browse/JBJCA-126
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 14:41:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-127) JBoss MC Dependency
	2.0.8.GA
Message-ID: <1297570986.1248720089465.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss MC Dependency 2.0.8.GA
----------------------------

                 Key: JBJCA-127
                 URL: https://jira.jboss.org/jira/browse/JBJCA-127
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 14:43:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-128) JBoss MC Kernel
	2.0.8.GA
Message-ID: <1869359378.1248720209164.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss MC Kernel 2.0.8.GA
------------------------

                 Key: JBJCA-128
                 URL: https://jira.jboss.org/jira/browse/JBJCA-128
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 14:43:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 27 Jul 2009 14:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-129) JBoss VFS 2.1.2.GA
Message-ID: <1486842312.1248720209260.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss VFS 2.1.2.GA
------------------

                 Key: JBJCA-129
                 URL: https://jira.jboss.org/jira/browse/JBJCA-129
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 16:21:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jul 2009 16:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-22) Log file is
 randomly truncated when configured from JBossMC/JBossAS
Message-ID: <30688019.1248726089233.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Log file is randomly truncated when configured from JBossMC/JBossAS
-------------------------------------------------------------------

                 Key: JBLOGGING-22
                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-22
             Project: JBoss Logging
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: jboss-logmanager
    Affects Versions: 1.1.0.CR4-jboss-logmanager
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 1.1.0.CR5-jboss-logmanager


Due to strangeness in the way that JBossMC's BeanMetaDataBuilder.addProperty() method works, the file name of the rotating file handlers is sometimes (but not always) set before the append flag, causing the file to be truncated even if append was set to true.

Add constructors such that both properties can be set simultaneously to work around this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 16:23:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jul 2009 16:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBLOGGING-13) Only copy log
 level config over when receiving a JMX notification of type
 "jboss.logging.log4j.reconfigure"
In-Reply-To: <29600234.1236708322487.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <937727644.1248726209217.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated JBLOGGING-13:
---------------------------------

    Assignee:     (was: David Lloyd)


> Only copy log level config over when receiving a JMX notification of type "jboss.logging.log4j.reconfigure"
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-13
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-13
>             Project: JBoss Logging
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logbridge
>    Affects Versions: 1.0.0.CR2-jboss-logbridge
>            Reporter: David Lloyd
>             Fix For: 1.0.1.GA-jboss-logbridge
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 16:55:30 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jul 2009 16:55:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBLOGGING-20) JDK loggign
 isLoggable(Level.FINEST) returns false with Log4J backend
In-Reply-To: <12251162.1245835856606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <832782688.1248728130869.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBLOGGING-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477811#action_12477811 ] 

David Lloyd commented on JBLOGGING-20:
--------------------------------------

Any chance you can hunt down where this problem occurs, and possibly come up with a patch?  The code lives here: http://anonsvn.jboss.org/repos/common/jboss-logbridge/trunk/

> JDK loggign isLoggable(Level.FINEST) returns false with Log4J backend
> ---------------------------------------------------------------------
>
>                 Key: JBLOGGING-20
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-20
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logbridge
>         Environment: JBoss 5.1.0, JDK 1.6u13
>            Reporter: Ondrej Medek
>            Assignee: Dimitris Andreadis
>
> I have code using JDK logging like:
> if (LOG.isLoggable(Level.FINEST)) {
>   LOG.finest("added into list: " + something);
> }
> I have no log. When I use just
> LOG.finest("added into list: " + something);
> I got a log in the log file.
> I use JBoss with Log4J. It is configured to log ALL stuff.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 16:55:31 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jul 2009 16:55:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBLOGGING-20) JDK loggign
 isLoggable(Level.FINEST) returns false with Log4J backend
In-Reply-To: <12251162.1245835856606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <89972444.1248728131004.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned JBLOGGING-20:
------------------------------------

    Assignee: David Lloyd  (was: Dimitris Andreadis)


> JDK loggign isLoggable(Level.FINEST) returns false with Log4J backend
> ---------------------------------------------------------------------
>
>                 Key: JBLOGGING-20
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-20
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logbridge
>         Environment: JBoss 5.1.0, JDK 1.6u13
>            Reporter: Ondrej Medek
>            Assignee: David Lloyd
>
> I have code using JDK logging like:
> if (LOG.isLoggable(Level.FINEST)) {
>   LOG.finest("added into list: " + something);
> }
> I have no log. When I use just
> LOG.finest("added into list: " + something);
> I got a log in the log file.
> I use JBoss with Log4J. It is configured to log ALL stuff.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 16:57:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jul 2009 16:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBLOGGING-6) DatasourceAppender
In-Reply-To: <27181334.1219183415489.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1647530091.1248728249305.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned JBLOGGING-6:
-----------------------------------

    Assignee: David Lloyd  (was: Dimitris Andreadis)


> DatasourceAppender
> ------------------
>
>                 Key: JBLOGGING-6
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-6
>             Project: JBoss Logging
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-log4j
>            Reporter: Luca Stancapiano
>            Assignee: David Lloyd
>             Fix For:  2.0.7.GA-log4j
>
>         Attachments: DatasourceAppender.java
>
>
> hi.... what do you think about a DatasourceAppender? This is very simple. It overrides getConnection and closeConnection methods of org.apache.log4j.jdbc.JDBCAppender class and it is configurable by a *-log4j.xml file. Here there is an example of xml file:
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false">
>   
>    <appender name="DATABASE" class="org.jboss.logging.appender.DatasourceAppender">
>    	  <param name="Threshold" value="INFO"/>
>    	  <param name="datasource" value="java:/PortalDS"/>
>    	  <layout class="org.apache.log4j.PatternLayout">
> 		 <param name="ConversionPattern" value=
> 		"INSERT INTO JBP_LOGGING_SAMPLES_USERS (log_date, log_type, log_user, operation) VALUES ( '%d{yyyy-MM-dd HH:mm:ss.SSS}','%p', '%C;%L', '%C;%L')"/>
>       </layout>
>    </appender>
>    
>    <category name="org.jboss.portal.core.identity.UsersActivityStatsServiceImpl">
>       <appender-ref ref="DATABASE"/>
>    </category>
>    
> </log4j:configuration>
> it is the same configuration for JDBCAppender but there is a 'datasource' parameter so you can specify the datasource location. Below there is the whole class:
> /*
>  * JBoss, Home of Professional Open Source
>  * Copyright 2005, JBoss Inc., and individual contributors as indicated
>  * by the @authors tag. See the copyright.txt in the distribution for a
>  * full listing of individual contributors.
>  *
>  * This is free software; you can redistribute it and/or modify it
>  * under the terms of the GNU Lesser General Public License as
>  * published by the Free Software Foundation; either version 2.1 of
>  * the License, or (at your option) any later version.
>  *
>  * This software is distributed in the hope that it will be useful,
>  * but WITHOUT ANY WARRANTY; without even the implied warranty of
>  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>  * Lesser General Public License for more details.
>  *
>  * You should have received a copy of the GNU Lesser General Public
>  * License along with this software; if not, write to the Free
>  * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
>  * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
>  */
> package org.jboss.logging.appender;
> import java.sql.Connection;
> import java.sql.SQLException;
> import javax.naming.InitialContext;
> import javax.naming.NamingException;
> import javax.sql.DataSource;
> /**
>  * An extension of the default Log4j JDBCAppender which will use a datasource to
>  * handle datas into database.
>  * 
>  * @version <tt>$Revision: 1958 $</tt>
>  * @author <a href="mailto:jedim at vige.it">Luca Stancapiano</a>
>  */
> public class DatasourceAppender extends org.apache.log4j.jdbc.JDBCAppender {
> 	/**
> 	 * URL of the DB for default connection handling
> 	 */
> 	protected String datasource = "java:/DefaultDS";
> 	protected DataSource ds;
> 	public void setDatasource(final String datasource) {
> 		this.datasource = datasource;
> 	}
> 	/**
> 	 * I override this method to get a connection from datasource.
> 	 */
> 	protected Connection getConnection() throws SQLException {
> 		if (connection == null || connection.isClosed()) {
> 			if (ds == null)
> 				try {
> 					InitialContext ic = new InitialContext();
> 					ds = (DataSource) ic.lookup(datasource);
> 				} catch (NamingException e) {
> 					e.printStackTrace();
> 				}
> 			connection = ds.getConnection();
> 		}
> 		return connection;
> 	}
> 	protected void closeConnection(Connection con) {
> 		try {
> 			connection.close();
> 		} catch (SQLException ex) {
> 			ex.printStackTrace();
> 		}
> 	}
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 16:58:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 27 Jul 2009 16:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBLOGGING-6)
	DatasourceAppender
In-Reply-To: <27181334.1219183415489.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1031418111.1248728309795.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBLOGGING-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477813#action_12477813 ] 

David Lloyd commented on JBLOGGING-6:
-------------------------------------

Any chance you can port this to use JBoss LogManager (see http://anonsvn.jboss.org/repos/common/jboss-logmanager/trunk for the source code)?  If you do so, and you include the test cases, I can merge it into this project.

> DatasourceAppender
> ------------------
>
>                 Key: JBLOGGING-6
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-6
>             Project: JBoss Logging
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-log4j
>            Reporter: Luca Stancapiano
>            Assignee: David Lloyd
>             Fix For:  2.0.7.GA-log4j
>
>         Attachments: DatasourceAppender.java
>
>
> hi.... what do you think about a DatasourceAppender? This is very simple. It overrides getConnection and closeConnection methods of org.apache.log4j.jdbc.JDBCAppender class and it is configurable by a *-log4j.xml file. Here there is an example of xml file:
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false">
>   
>    <appender name="DATABASE" class="org.jboss.logging.appender.DatasourceAppender">
>    	  <param name="Threshold" value="INFO"/>
>    	  <param name="datasource" value="java:/PortalDS"/>
>    	  <layout class="org.apache.log4j.PatternLayout">
> 		 <param name="ConversionPattern" value=
> 		"INSERT INTO JBP_LOGGING_SAMPLES_USERS (log_date, log_type, log_user, operation) VALUES ( '%d{yyyy-MM-dd HH:mm:ss.SSS}','%p', '%C;%L', '%C;%L')"/>
>       </layout>
>    </appender>
>    
>    <category name="org.jboss.portal.core.identity.UsersActivityStatsServiceImpl">
>       <appender-ref ref="DATABASE"/>
>    </category>
>    
> </log4j:configuration>
> it is the same configuration for JDBCAppender but there is a 'datasource' parameter so you can specify the datasource location. Below there is the whole class:
> /*
>  * JBoss, Home of Professional Open Source
>  * Copyright 2005, JBoss Inc., and individual contributors as indicated
>  * by the @authors tag. See the copyright.txt in the distribution for a
>  * full listing of individual contributors.
>  *
>  * This is free software; you can redistribute it and/or modify it
>  * under the terms of the GNU Lesser General Public License as
>  * published by the Free Software Foundation; either version 2.1 of
>  * the License, or (at your option) any later version.
>  *
>  * This software is distributed in the hope that it will be useful,
>  * but WITHOUT ANY WARRANTY; without even the implied warranty of
>  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>  * Lesser General Public License for more details.
>  *
>  * You should have received a copy of the GNU Lesser General Public
>  * License along with this software; if not, write to the Free
>  * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
>  * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
>  */
> package org.jboss.logging.appender;
> import java.sql.Connection;
> import java.sql.SQLException;
> import javax.naming.InitialContext;
> import javax.naming.NamingException;
> import javax.sql.DataSource;
> /**
>  * An extension of the default Log4j JDBCAppender which will use a datasource to
>  * handle datas into database.
>  * 
>  * @version <tt>$Revision: 1958 $</tt>
>  * @author <a href="mailto:jedim at vige.it">Luca Stancapiano</a>
>  */
> public class DatasourceAppender extends org.apache.log4j.jdbc.JDBCAppender {
> 	/**
> 	 * URL of the DB for default connection handling
> 	 */
> 	protected String datasource = "java:/DefaultDS";
> 	protected DataSource ds;
> 	public void setDatasource(final String datasource) {
> 		this.datasource = datasource;
> 	}
> 	/**
> 	 * I override this method to get a connection from datasource.
> 	 */
> 	protected Connection getConnection() throws SQLException {
> 		if (connection == null || connection.isClosed()) {
> 			if (ds == null)
> 				try {
> 					InitialContext ic = new InitialContext();
> 					ds = (DataSource) ic.lookup(datasource);
> 				} catch (NamingException e) {
> 					e.printStackTrace();
> 				}
> 			connection = ds.getConnection();
> 		}
> 		return connection;
> 	}
> 	protected void closeConnection(Connection con) {
> 		try {
> 			connection.close();
> 		} catch (SQLException ex) {
> 			ex.printStackTrace();
> 		}
> 	}
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 18:51:29 2009
From: jira-events at lists.jboss.org (Alex Skor (JIRA))
Date: Mon, 27 Jul 2009 18:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7071) use-try-lock
 option in data source configuration files is ignored
In-Reply-To: <329869123.1246546191859.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1351349700.1248735089333.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477827#action_12477827 ] 

Alex Skor commented on JBAS-7071:
---------------------------------

guys, could you attach a JAR file with this change? I don't feel safe building JBoss from source code myself. so, until this problem is fixed in the new build it would be great if you could provide a JAR file people could use with Jboss 5.1.0GA.

> use-try-lock option in data source configuration files is ignored
> -----------------------------------------------------------------
>
>                 Key: JBAS-7071
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7071
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Windows XP Professional V2002, service pack 3
>            Reporter: Mike Conner
>            Assignee: Jesper Pedersen
>            Priority: Minor
>
> (FYI  your "READ THIS BEFORE ENTERING NEW REPORTS" points to a  "You caught us doing a little maintenance..." page, so pardon me if I missed something in procedure. )
> The data source configuration property "use-try-lock" is effectively ignored.
> This is because the value is defined in configuration as a long, but the object that is actually set on  an
> org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory  extends 
>    org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnectionFactory
> This class defines it as taking an int, not a long:
>    public void setUseTryLock(int useTryLock)
> As such, reflection in ManagedConnectionFactoryDeployment.setManagedConnectionFactoryAttribute() does not find the method and simply logs it at a trace level, so the value never gets set.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 21:32:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 27 Jul 2009 21:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1869) Upgrade
 jboss-ejb3-build dependency in testsuite to 1.0.5-SNAPSHOT
In-Reply-To: <1684396779.1247485589262.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1464931947.1248744749229.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1869.
------------------------------------

    Resolution: Done


> Upgrade jboss-ejb3-build dependency in testsuite to 1.0.5-SNAPSHOT
> ------------------------------------------------------------------
>
>                 Key: EJBTHREE-1869
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1869
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: testsuite
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> The jobs on slaves of mike are failing to resolve the 1.0.4-SNAPSHOT or 1.0.4 of jboss-ejb3-build for 2 reasons:
> 1) The 1.0.4-SNAPSHOT of jboss-ejb3-build is not available through the relative path
> 2) The Maven settings on slaves are not pointing to jboss repo.
> As a workaround, upgrade the jboss-ejb3-build dependency in testsuite to 1.0.5-SNAPSHOT (so that it is resolved locally through relative path).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 22:35:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Mon, 27 Jul 2009 22:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-1077) Fix problem in
 CompressingMarshaller
In-Reply-To: <21329107.1230710934327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <35203460.1248748529373.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBREM-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477836#action_12477836 ] 

Ron Sigal commented on JBREM-1077:
----------------------------------

Applied Doychin Bondzhev's fix to branches 2.2 and 2.x.  Also, added buffered streams to branch 2.2.

Testing:

  * Unit test: org.jboss.test.remoting.marshall.compress.NewCompressingMarshallerTestCase

  * Also, tested with an EJB3 in EAP 4.3.0.GA_CP04

Waiting for results in hudson.

> Fix problem in CompressingMarshaller
> ------------------------------------
>
>                 Key: JBREM-1077
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1077
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11
>            Reporter: Ron Sigal
>            Assignee: Ron Sigal
>             Fix For: 2.5.2 (Flounder), 2.2.3.SP1
>
>         Attachments: CompressionInvokerMarshaller.java, CompressionInvokerUnmarshaller.java
>
>
> In org.jboss.remoting.marshal.compress.CompressingMarshaller.write(),
>       gzos.finish();
>       oos.flush();
> should be
>       oos.flush();
>       bos.flush();
>       gzos.flush();
>       gzos.finish();
> as it is on the 2.x branch.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 22:39:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Mon, 27 Jul 2009 22:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-1077) Fix problem in
 CompressingMarshaller
In-Reply-To: <21329107.1230710934327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <301684494.1248748769272.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBREM-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ron Sigal updated JBREM-1077:
-----------------------------

    Attachment: jboss-remoting.jar


Attaching jboss-remoting.jar from 2.2 branch.  It will print 

   Remoting version: 2.2.3.SP1-preview: 7/27/09-22:21

when it is loaded.

> Fix problem in CompressingMarshaller
> ------------------------------------
>
>                 Key: JBREM-1077
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1077
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11
>            Reporter: Ron Sigal
>            Assignee: Ron Sigal
>             Fix For: 2.5.2 (Flounder), 2.2.3.SP1
>
>         Attachments: CompressionInvokerMarshaller.java, CompressionInvokerUnmarshaller.java, jboss-remoting.jar
>
>
> In org.jboss.remoting.marshal.compress.CompressingMarshaller.write(),
>       gzos.finish();
>       oos.flush();
> should be
>       oos.flush();
>       bos.flush();
>       gzos.flush();
>       gzos.finish();
> as it is on the 2.x branch.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 22:41:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Mon, 27 Jul 2009 22:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-1077) Fix problem in
 CompressingMarshaller
In-Reply-To: <21329107.1230710934327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1170542219.1248748889666.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBREM-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ron Sigal updated JBREM-1077:
-----------------------------

    Attachment: jboss-remoting.jar


Attached jboss-remoting.jar from branch 2.x.  It will print

  Remoting version: 2.5.2 (Flounder) preview: 7/27/09-20:53

when it is loaded.

> Fix problem in CompressingMarshaller
> ------------------------------------
>
>                 Key: JBREM-1077
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1077
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11
>            Reporter: Ron Sigal
>            Assignee: Ron Sigal
>             Fix For: 2.5.2 (Flounder), 2.2.3.SP1
>
>         Attachments: CompressionInvokerMarshaller.java, CompressionInvokerUnmarshaller.java, jboss-remoting.jar, jboss-remoting.jar
>
>
> In org.jboss.remoting.marshal.compress.CompressingMarshaller.write(),
>       gzos.finish();
>       oos.flush();
> should be
>       oos.flush();
>       bos.flush();
>       gzos.flush();
>       gzos.finish();
> as it is on the 2.x branch.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Jul 27 22:47:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Mon, 27 Jul 2009 22:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-1077) Fix problem in
 CompressingMarshaller
In-Reply-To: <21329107.1230710934327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <559538465.1248749249942.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBREM-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ron Sigal updated JBREM-1077:
-----------------------------

    Attachment: ejb3-compression.tgz


Attaching tgz file with EJB3 example.  

"ant" will deploy the example the example to JBossAS (according to the value of jboss.home in the local.properties file). 

"ant run" will run the example

> Fix problem in CompressingMarshaller
> ------------------------------------
>
>                 Key: JBREM-1077
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1077
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11
>            Reporter: Ron Sigal
>            Assignee: Ron Sigal
>             Fix For: 2.5.2 (Flounder), 2.2.3.SP1
>
>         Attachments: CompressionInvokerMarshaller.java, CompressionInvokerUnmarshaller.java, ejb3-compression.tgz, jboss-remoting.jar, jboss-remoting.jar
>
>
> In org.jboss.remoting.marshal.compress.CompressingMarshaller.write(),
>       gzos.finish();
>       oos.flush();
> should be
>       oos.flush();
>       bos.flush();
>       gzos.flush();
>       gzos.finish();
> as it is on the 2.x branch.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 00:14:29 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Tue, 28 Jul 2009 00:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
Message-ID: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Unable to consume more than  777,000 messages
---------------------------------------------

                 Key: JBMESSAGING-1693
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0
         Environment: Windows Vista, 32 bit, 2GB RAM
            Reporter: Bijith Kumar
            Assignee: Tim Fox
            Priority: Critical


Using messaging-2.0.0.BETA3 stand alone non-clustered
-------------------------------------------------------------------------------
I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
 <global-page-size>10485760</global-page-size>
<paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 

Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
-Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

Please find the attached java files. Test instructions are given below
1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
4) Observe from JConsole that after the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
5) Observe that after a while consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by substracting MessageCount  from messagedAdded. Following are the values I got for last three runs
Messages Consumed = messagedAdded -  MessageCount  
 a) 800246 - 23246 = 777000
 b) 799037 - 22037 = 777000
 c)  799037 - 22037 = 777000

It seems the number of messages consumed (777000 in above case) is driven by message size.  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 00:16:49 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Tue, 28 Jul 2009 00:16:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
In-Reply-To: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1144808404.1248754609456.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1693:
--------------------------------------

    Attachment: src.rar


Attaching files

> Unable to consume more than  777,000 messages
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1693
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>         Environment: Windows Vista, 32 bit, 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>            Priority: Critical
>         Attachments: src.rar
>
>
> Using messaging-2.0.0.BETA3 stand alone non-clustered
> -------------------------------------------------------------------------------
> I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
>  <global-page-size>10485760</global-page-size>
> <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 
> Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
> -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
> Please find the attached java files. Test instructions are given below
> 1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
> 2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
> 3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
> 4) Observe from JConsole that after the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
> 5) Observe that after a while consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by substracting MessageCount  from messagedAdded. Following are the values I got for last three runs
> Messages Consumed = messagedAdded -  MessageCount  
>  a) 800246 - 23246 = 777000
>  b) 799037 - 22037 = 777000
>  c)  799037 - 22037 = 777000
> It seems the number of messages consumed (777000 in above case) is driven by message size.  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 00:32:29 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Tue, 28 Jul 2009 00:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
In-Reply-To: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1218801317.1248755549383.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1693:
--------------------------------------

    Description: 
Using messaging-2.0.0.BETA3 stand alone non-clustered
-------------------------------------------------------------------------------
I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
 <global-page-size>10485760</global-page-size>
<paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 

Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
-Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

Please find the attached java files. Test instructions are given below
1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by substracting MessageCount  from messagedAdded. Following are the values I got for last three runs
Messages Consumed = messagedAdded -  MessageCount  
 a) 800246 - 23246 = 777000
 b) 799037 - 22037 = 777000
 c)  799037 - 22037 = 777000

It seems the number of messages consumed (777000 in above case) is driven by message size.  Because, when I tried another message, the consumption hanged after 780,000 messages.

  was:
Using messaging-2.0.0.BETA3 stand alone non-clustered
-------------------------------------------------------------------------------
I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
 <global-page-size>10485760</global-page-size>
<paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 

Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
-Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

Please find the attached java files. Test instructions are given below
1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
4) Observe from JConsole that after the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
5) Observe that after a while consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by substracting MessageCount  from messagedAdded. Following are the values I got for last three runs
Messages Consumed = messagedAdded -  MessageCount  
 a) 800246 - 23246 = 777000
 b) 799037 - 22037 = 777000
 c)  799037 - 22037 = 777000

It seems the number of messages consumed (777000 in above case) is driven by message size.  Because, when I tried another message, the consumption hanged after 780,000 messages.



> Unable to consume more than  777,000 messages
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1693
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>         Environment: Windows Vista, 32 bit, 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>            Priority: Critical
>         Attachments: src.rar
>
>
> Using messaging-2.0.0.BETA3 stand alone non-clustered
> -------------------------------------------------------------------------------
> I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
>  <global-page-size>10485760</global-page-size>
> <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 
> Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
> -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
> Please find the attached java files. Test instructions are given below
> 1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
> 2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
> 3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
> 4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
> 5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by substracting MessageCount  from messagedAdded. Following are the values I got for last three runs
> Messages Consumed = messagedAdded -  MessageCount  
>  a) 800246 - 23246 = 777000
>  b) 799037 - 22037 = 777000
>  c)  799037 - 22037 = 777000
> It seems the number of messages consumed (777000 in above case) is driven by message size.  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 00:32:29 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Tue, 28 Jul 2009 00:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
In-Reply-To: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <756939980.1248755549515.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1693:
--------------------------------------

    Description: 
Using messaging-2.0.0.BETA3 stand alone non-clustered
-------------------------------------------------------------------------------
I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
 <global-page-size>10485760</global-page-size>
<paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 

Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
-Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

Please find the attached java files. Test instructions are given below
1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
Messages Consumed = messagesAdded -  MessageCount  
 a) 800246 - 23246 = 777000
 b) 799037 - 22037 = 777000
 c)  799037 - 22037 = 777000

It seems the number of messages consumed (777000 in above case) is driven by message size.  Because, when I tried another message, the consumption hanged after 780,000 messages.

  was:
Using messaging-2.0.0.BETA3 stand alone non-clustered
-------------------------------------------------------------------------------
I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
 <global-page-size>10485760</global-page-size>
<paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 

Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
-Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

Please find the attached java files. Test instructions are given below
1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by substracting MessageCount  from messagedAdded. Following are the values I got for last three runs
Messages Consumed = messagedAdded -  MessageCount  
 a) 800246 - 23246 = 777000
 b) 799037 - 22037 = 777000
 c)  799037 - 22037 = 777000

It seems the number of messages consumed (777000 in above case) is driven by message size.  Because, when I tried another message, the consumption hanged after 780,000 messages.



> Unable to consume more than  777,000 messages
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1693
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>         Environment: Windows Vista, 32 bit, 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>            Priority: Critical
>         Attachments: src.rar
>
>
> Using messaging-2.0.0.BETA3 stand alone non-clustered
> -------------------------------------------------------------------------------
> I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
>  <global-page-size>10485760</global-page-size>
> <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 
> Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
> -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
> Please find the attached java files. Test instructions are given below
> 1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
> 2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
> 3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
> 4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
> 5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
> Messages Consumed = messagesAdded -  MessageCount  
>  a) 800246 - 23246 = 777000
>  b) 799037 - 22037 = 777000
>  c)  799037 - 22037 = 777000
> It seems the number of messages consumed (777000 in above case) is driven by message size.  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 02:08:29 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Tue, 28 Jul 2009 02:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
In-Reply-To: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2027383767.1248761309246.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1693:
--------------------------------------

    Description: 
Using messaging-2.0.0.BETA3 stand alone non-clustered
-------------------------------------------------------------------------------
I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
 <global-page-size>10485760</global-page-size>
<paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 

Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
-Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

Please find the attached java files. Test instructions are given below
1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
Messages Consumed = messagesAdded -  MessageCount  
 a) 800246 - 23246 = 777000
 b) 799037 - 22037 = 777000
 c)  799037 - 22037 = 777000

It seems the number of messages consumed (777000 in above case) is driven by message size (and Queue size).  Because, when I tried another message, the consumption hanged after 780,000 messages.

  was:
Using messaging-2.0.0.BETA3 stand alone non-clustered
-------------------------------------------------------------------------------
I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
 <global-page-size>10485760</global-page-size>
<paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 

Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
-Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

Please find the attached java files. Test instructions are given below
1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
Messages Consumed = messagesAdded -  MessageCount  
 a) 800246 - 23246 = 777000
 b) 799037 - 22037 = 777000
 c)  799037 - 22037 = 777000

It seems the number of messages consumed (777000 in above case) is driven by message size.  Because, when I tried another message, the consumption hanged after 780,000 messages.



> Unable to consume more than  777,000 messages
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1693
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>         Environment: Windows Vista, 32 bit, 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>            Priority: Critical
>         Attachments: src.rar
>
>
> Using messaging-2.0.0.BETA3 stand alone non-clustered
> -------------------------------------------------------------------------------
> I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
>  <global-page-size>10485760</global-page-size>
> <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 
> Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
> -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
> Please find the attached java files. Test instructions are given below
> 1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
> 2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
> 3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
> 4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
> 5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
> Messages Consumed = messagesAdded -  MessageCount  
>  a) 800246 - 23246 = 777000
>  b) 799037 - 22037 = 777000
>  c)  799037 - 22037 = 777000
> It seems the number of messages consumed (777000 in above case) is driven by message size (and Queue size).  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 03:27:30 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 28 Jul 2009 03:27:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7126) Include farm folder
 in the VFSCache permanent roots configuration
Message-ID: <535403161.1248766050126.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Include farm folder in the VFSCache permanent roots configuration
-----------------------------------------------------------------

                 Key: JBAS-7126
                 URL: https://jira.jboss.org/jira/browse/JBAS-7126
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: VFS
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: jaikiran pai
            Assignee: jaikiran pai


The "farm" folder is missing from the VFSCache configuration for permanent roots. This results in the well-known disk space usage issue with tmp files in AS-5.x.

Adding the "farm" folder URL should fix the issue.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 03:52:42 2009
From: jira-events at lists.jboss.org (Ondrej Medek (JIRA))
Date: Tue, 28 Jul 2009 03:52:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBLOGGING-20) JDK loggign
 isLoggable(Level.FINEST) returns false with Log4J backend
In-Reply-To: <12251162.1245835856606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <699248592.1248767562759.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBLOGGING-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477856#action_12477856 ] 

Ondrej Medek commented on JBLOGGING-20:
---------------------------------------

Well, I do not know exactly, where is the problem, but I think I have found two bugs.

The LOG is org.jboss.logmanager.LoggerInstance and this class is subclass of java.util.logging.Logger. The LoggerInstance class overrides the isLoggable(Level) method from the Logger class. This overridden method LoggerInstance.isLoggable(Level) uses a new value called effectiveLevel, which is:

effectiveLevel = 800, i.e. default value I guess, when I have configured to log ALL stuff for my category in log4j config file. It should be INT.MIN_VALUE (= Level.ALL.intValue()) instead.
effectiveLevel = 400, when I have configured to log TRACE stuff for my category in log4j config file. I.e. is is the same value, as Level.FINE.

Bug 1) Setting ALL level for the category in config file should set the effectiveLevel to Level.ALL.intValue().

Bug 2) Setting TRACE level for the category in config file makes the LOG.isLoggable(FINEST) always false, but LOG.finest("...") does make a log.

IMHO this "LoggerInstance.effectiveLevel" stuff is half baken: it is used only in isLoggable(), but is not used in the log() methods (doLog, fine, finer, finest, ...). Maybe it should be removed and the original Logger.levelValue should be used instead?  Then LoggerInstance would not need to override isLoggable().

> JDK loggign isLoggable(Level.FINEST) returns false with Log4J backend
> ---------------------------------------------------------------------
>
>                 Key: JBLOGGING-20
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-20
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logbridge
>         Environment: JBoss 5.1.0, JDK 1.6u13
>            Reporter: Ondrej Medek
>            Assignee: David Lloyd
>
> I have code using JDK logging like:
> if (LOG.isLoggable(Level.FINEST)) {
>   LOG.finest("added into list: " + something);
> }
> I have no log. When I use just
> LOG.finest("added into list: " + something);
> I got a log in the log file.
> I use JBoss with Log4J. It is configured to log ALL stuff.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 04:00:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 28 Jul 2009 04:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7126) Include farm folder
 in the VFSCache permanent roots configuration
In-Reply-To: <535403161.1248766050126.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <634410491.1248768029238.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBAS-7126.
--------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1
                   JBossAS-6.0.0.Alpha1
       Resolution: Done


Added 

<entry>
		<key>${jboss.server.home.url}farm</key>
		<value><inject bean="VfsNamesExceptionHandler"/></value>
	</entry>

to [Branch_5_x/trunk]/server/src/etc/conf/all/bootstrap/vfs.xml. This file gets reused during AS build in the "default" server configuration too. With the inclusion of "farm" folder in the VFSCache configuration, both the "all" and "default" server configuration boot up fine (even if farm folder is non-existent in default server configuration). 

Marking as resolved.


> Include farm folder in the VFSCache permanent roots configuration
> -----------------------------------------------------------------
>
>                 Key: JBAS-7126
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7126
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: VFS
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1
>
>
> The "farm" folder is missing from the VFSCache configuration for permanent roots. This results in the well-known disk space usage issue with tmp files in AS-5.x.
> Adding the "farm" folder URL should fix the issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 04:53:29 2009
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Tue, 28 Jul 2009 04:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1687) Transaction
 management/demarcation and ack modes/session creation broken in JCA RA
In-Reply-To: <615256574.1247823389304.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <733968770.1248771209574.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Taylor closed JBMESSAGING-1687.
------------------------------------

    Fix Version/s: 2.0.0.beta4
                       (was: 2.0.0)
       Resolution: Done


> Transaction management/demarcation and ack modes/session creation broken in JCA RA
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1687
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1687
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>            Assignee: Andy Taylor
>            Priority: Critical
>             Fix For: 2.0.0.beta4
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 05:01:29 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Tue, 28 Jul 2009 05:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7046) Support CDI
 injection into Java EE component classes
In-Reply-To: <24256304.1245752876415.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1075443976.1248771689161.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pete Muir updated JBAS-7046:
----------------------------

    Summary: Support CDI injection into Java EE component classes  (was: Support CDI injection into managed Servlet objects)


> Support CDI injection into Java EE component classes
> ----------------------------------------------------
>
>                 Key: JBAS-7046
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7046
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Pete Muir
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 05:07:29 2009
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 28 Jul 2009 05:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7046) Support CDI
 injection into Java EE component classes
In-Reply-To: <24256304.1245752876415.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <751369223.1248772049289.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477863#action_12477863 ] 

Jozef Hartinger commented on JBAS-7046:
---------------------------------------

covered by JSR-299 TCK
org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.InjectionIntoNonContextualComponentTest.testInjectionIntoServlet()
org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.InjectionIntoNonContextualComponentTest.testInjectionIntoFilter()
org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.InjectionIntoNonContextualComponentTest.testInjectionIntoServletListener()
org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.InjectionIntoNonContextualComponentTest.testInjectionIntoTagHandler()
org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.InjectionIntoNonContextualComponentTest.testInjectionIntoTagLibraryListener()
org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.InjectionIntoNonContextualComponentTest.testInjectionIntoJSFManagedBean()
org.jboss.jsr299.tck.tests.lookup.injection.enterprise.SessionBeanInjectionTest.testInjectionOnEJBInterceptor()

> Support CDI injection into Java EE component classes
> ----------------------------------------------------
>
>                 Key: JBAS-7046
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7046
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Pete Muir
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 05:49:29 2009
From: jira-events at lists.jboss.org (Miro Selent (JIRA))
Date: Tue, 28 Jul 2009 05:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1016) memory leak in GMS
	protocol
Message-ID: <1523793676.1248774569291.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

memory leak in GMS protocol
---------------------------

                 Key: JGRP-1016
                 URL: https://jira.jboss.org/jira/browse/JGRP-1016
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.7
            Reporter: Miro Selent
            Assignee: Bela Ban
            Priority: Critical


Found in org.jgroups.protocols.pbcast.GMS in a scenario where members were killed and restarted very frequently and one member is persistently running. The memory consumption icreased very quickly until OutOfMemory.

Our analysis with JProfiler leads to the following assumption:
The number of org.jgroups.stack.IpAddress held by merge_ack_collector icreases every time a member was (re)started. 
These instances were never removed because no MERGE events occured. This is completely clear since there was only one coordinator (the long running member). 
If GMS receives no MERGE event it never cleans up the stored IpAddress instances in the merge_ack_collector.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 06:39:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 28 Jul 2009 06:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1388178155.1248777569224.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477873#action_12477873 ] 

Howard Gao commented on JBMESSAGING-1685:
-----------------------------------------

Hi Martin,

Thanks for the info. I examined my first test and found it's not a valid one. The reason is that for every loop it sends 200 messages and only received one. So the 199 messages are left in the queue. As you added the loops the message are accumulated and eventually use up the memory.

I attached a new test that comsumes all the messages after roll back so no messages are left in each loop. And it passes 1000 loops safely.

To run the test, you need to add "MaxDeliveryAttempts" to 2000 in the queue configuration file so message won't be put to the DLQ after 10 times of roll backs.

Can you take a look (it's QueueExampleLong2.java)? Thanks.

Howard



> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java, QueueExampleLong.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 06:45:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Tue, 28 Jul 2009 06:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2035891158.1248777929602.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao updated JBMESSAGING-1685:
------------------------------------

    Attachment: QueueExampleLong2.java


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java, QueueExampleLong.java, QueueExampleLong2.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 08:15:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 28 Jul 2009 08:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1694) -1 is a valid
 value for connection-ttl & client-failure-check -period
Message-ID: <258915794.1248783329841.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

-1 is a valid value for connection-ttl & client-failure-check -period
---------------------------------------------------------------------

                 Key: JBMESSAGING-1694
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1694
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Facade
    Affects Versions: 2.0.0.beta4
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 2.0.0


in JMSServerDeployer, we validate that client-failure-check-period & connection-ttl values are greater or equals to zero.
This is not correct, these values can be equals to -1 (meaning infinite) or greater than 0

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 08:15:30 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 28 Jul 2009 08:15:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1694) -1 is a valid
 value for connection-ttl & client-failure-check -period
In-Reply-To: <258915794.1248783329841.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1470205708.1248783330002.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1694.
------------------------------------

    Resolution: Done


fixed in the trunk

> -1 is a valid value for connection-ttl & client-failure-check -period
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1694
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1694
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 2.0.0.beta4
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> in JMSServerDeployer, we validate that client-failure-check-period & connection-ttl values are greater or equals to zero.
> This is not correct, these values can be equals to -1 (meaning infinite) or greater than 0

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 08:35:29 2009
From: jira-events at lists.jboss.org (Jean-David Maillefer (JIRA))
Date: Tue, 28 Jul 2009 08:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-216) Many of the schema
 and DTD on http://www.jboss.org/j2ee/ are invalid
Message-ID: <1516074926.1248784529231.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Many of the schema and DTD on http://www.jboss.org/j2ee/ are  invalid
---------------------------------------------------------------------

                 Key: JBMETA-216
                 URL: https://jira.jboss.org/jira/browse/JBMETA-216
             Project: JBoss Metadata
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: Irrelevant, except that I use eclipse Galileo to develop (and validate) the JBoss configuration files
            Reporter: Jean-David Maillefer
            Assignee: Alexey Loubyansky
            Priority: Minor


The following files available on the web (http://www.jboss.org/j2ee/) are not valid:

Description	Resource	Path	Location	Type
A '(' character or an element type is required in the declaration of element type "simpleType".	datatypes.dtd	/SITData/j2ee/dtd	line 95	DTD Problem
Type	Path	Resource	Location	Description
DTD Problem	j2ee/dtd	datatypes.dtd	line 95	A '(' character or an element type is required in the declaration of element type "simpleType".
DTD Problem	j2ee/dtd	jaws.dtd	line 13	The element 'cmp-field' has not been declared.
DTD Problem	j2ee/dtd	jboss-ds_5_0.dtd	line 34	The element 'background-validation-millis' has not been declared.
DTD Problem	j2ee/dtd	jboss-ds_5_0.dtd	line 417	The element 'background-validation-millis' has not been declared.
DTD Problem	j2ee/dtd	jboss-ds_5_0.dtd	line 425	The element 'background-validation-millis' has not been declared.
DTD Problem	j2ee/dtd	jboss-ds_5_0.dtd	line 49	The element 'background-validation-millis' has not been declared.
DTD Problem	j2ee/dtd	jboss-ds_5_0.dtd	line 62	The element 'background-validation-millis' has not been declared.
DTD Problem	j2ee/dtd	jboss-web_4_0.dtd	line 367	The element 'false' has not been declared.
DTD Problem	j2ee/dtd	jboss-web_4_0.dtd	line 367	The element 'true' has not been declared.
DTD Problem	j2ee/dtd	jboss-web_4_0.dtd	line 455	The element 'key' has not been declared.
DTD Problem	j2ee/dtd	jboss-web_4_0.dtd	line 455	The element 'value' has not been declared.
DTD Problem	j2ee/dtd	jboss-web_4_2.dtd	line 374	The element 'false' has not been declared.
DTD Problem	j2ee/dtd	jboss-web_4_2.dtd	line 374	The element 'true' has not been declared.
DTD Problem	j2ee/dtd	jboss-web_4_2.dtd	line 462	The element 'key' has not been declared.
DTD Problem	j2ee/dtd	jboss-web_4_2.dtd	line 462	The element 'value' has not been declared.
XML Schema Problem	j2ee/schema	jboss_5_0.xsd	line 410	cos-nonambig: "http://www.jboss.com/xml/ns/javaee":security-identity and "http://www.jboss.com/xml/ns/javaee":security-identity (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
XML Schema Problem	j2ee/schema	jboss_5_1.xsd	line 349	cos-nonambig: "http://www.jboss.com/xml/ns/javaee":security-identity and "http://www.jboss.com/xml/ns/javaee":security-identity (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
XML Schema Problem	j2ee/schema	jbxb_1_0.xsd	line 19	src-resolve.4.2: Error resolving component 'jbxb:package'. It was detected that 'jbxb:package' is in namespace 'http://www.jboss.org/xml/ns/jbxb', but components from this namespace are not referenceable from schema document 'file:///C:/eclipse-workspace/SITData/j2ee/schema/jbxb_1_0.xsd'. If this is the incorrect namespace, perhaps the prefix of 'jbxb:package' needs to be changed. If this is the correct namespace, then an appropriate 'import' tag should be added to 'file:///C:/eclipse-workspace/SITData/j2ee/schema/jbxb_1_0.xsd'.
XML Schema Problem	j2ee/schema	jbxb_1_0.xsd	line 94	src-element.3: Element 'class' has both a 'type' attribute and a 'anonymous type' child. Only one of these is allowed for an element.
XML Schema Problem	j2ee/schema	web-jsptaglibrary_2_0.xsd	line 1	Referenced file contains errors (j2ee/schema/j2ee_1_4.xsd).  Details: sch-props-correct.2: A schema cannot contain two global components with the same name; this schema contains two occurrences of "http://java.sun.com/xml/ns/j2ee,listenerType'. line 722


The following files available from SVN (JBossAS/projects/metadata/trunk/src/main/resources 90580) are not valid:
Type	Path	Resource	Location	Description	Fix
DTD Problem	j2ee/dtd	connector_1_6.dtd	line 78	The element 'required-inflow-context' has not been declared.	add missing declaration
DTD Problem	j2ee/dtd	datatypes.dtd	line 95	A '(' character or an element type is required in the declaration of element type "simpleType".	TODO
DTD Problem	j2ee/dtd	jaws.dtd	line 13	The element 'cmp-field' has not been declared.	add missing declaration
DTD Problem	j2ee/dtd	jboss-web_4_0.dtd	line 367	The element 'true' has not been declared.	add missing declaration
DTD Problem	j2ee/dtd	jboss-web_4_0.dtd	line 367	The element 'false' has not been declared.	add missing declaration
DTD Problem	j2ee/dtd	jboss-web_4_0.dtd	line 455	The element 'key' has not been declared.	add missing declaration
DTD Problem	j2ee/dtd	jboss-web_4_0.dtd	line 455	The element 'value' has not been declared.	add missing declaration
DTD Problem	j2ee/dtd	jboss-web_4_2.dtd	line 374	The element 'false' has not been declared.	add missing declaration
DTD Problem	j2ee/dtd	jboss-web_4_2.dtd	line 374	The element 'true' has not been declared.	add missing declaration
DTD Problem	j2ee/dtd	jboss-web_4_2.dtd	line 462	The element 'key' has not been declared.	add missing declaration
DTD Problem	j2ee/dtd	jboss-web_4_2.dtd	line 462	The element 'value' has not been declared.	add missing declaration
XML Schema Problem	j2ee/schema	jboss_5_1.xsd	line 1218	src-resolve: Cannot resolve the name 'jboss:webservice-descriptionType' to a(n) 'type definition' component.	update http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd to latest version
XML Schema Problem	j2ee/schema	jboss-web_5_1.xsd	line 95	src-resolve: Cannot resolve the name 'jboss:webservice-descriptionType' to a(n) 'type definition' component.	update http://www.jboss.org/j2ee/schema/jboss-common_5_1.xsd to latest version
XML Schema Problem	j2ee/schema	jbxb_1_0.xsd	line 19	src-resolve.4.2: Error resolving component 'jbxb:package'. It was detected that 'jbxb:package' is in namespace 'http://www.jboss.org/xml/ns/jbxb', but components from this namespace are not referenceable from schema document 'j2ee/schema/jbxb_1_0.xsd'. If this is the incorrect namespace, perhaps the prefix of 'jbxb:package' needs to be changed. If this is the correct namespace, then an appropriate 'import' tag should be added to 'j2ee/schema/jbxb_1_0.xsd'.	TODO
XML Schema Problem	j2ee/schema	jbxb_1_0.xsd	line 94	src-element.3: Element 'class' has both a 'type' attribute and a 'anonymous type' child. Only one of these is allowed for an element.	TODO
XML Schema Problem	j2ee/schema	web-jsptaglibrary_2_0.xsd	line 1	Referenced file contains errors (j2ee/schema/j2ee_1_4.xsd).  Details: sch-props-correct.2: A schema cannot contain two global components with the same name; this schema contains two occurrences of "http://java.sun.com/xml/ns/j2ee,listenerType'. line 722	TODO


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 09:29:29 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Tue, 28 Jul 2009 09:29:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1482870715.1248787769356.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------


hi howard, thanks for your feedback. now that all messages are received (and commited) the OOM condition no longer occurs. i'm sorry i did not figure out the issue in the test routine as well.
nevertheless the issue is still existent as the application guy does not issue a commit() until the message has been successfully processed (archived the document and updated some index tables). the application works in the same fashion as the main() method, it sleeps for a while, retries, rolls back, sleeps again. if the scanning process is heavily used hundreds of open messages queue up and are rolled back again and again. if the outage of the archive system or database server takes some time, the OOM occurs sooner or later.
what is expected is that if MaxDeliveryAttempts is reached, the message is discarded (or put to a DLQ, if defined) and the associated memory should be cleaned up. there should be no need to issue a commit(), the memory in my opinion should be freed at the latest when the connection is closed. as it is also done in our example (before going to sleep again).
thanks very much for your efforts putting into this.
kind regards martin

> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java, QueueExampleLong.java, QueueExampleLong2.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 09:29:29 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Tue, 28 Jul 2009 09:29:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7125) JMS Destinations:
 properties "Count" and "Time Last Update" are 0 after sending a message
Message-ID: <1027791533.1248787769488.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej ?i?ka updated JBAS-7125:
-------------------------------

    Description: 
After sending a message(s), some properties have bad values:

Count = 0,
Count Delta = 0,
Time Last Update = 0,

However, 

Depth	4	The current message count of pending messages within the queue waiting for dispatch
Depth Delta	3	The message count delta of pending messages since last method call

Did the meaning of  Count change?

I've looked at the queue MBean in JMX console, and there's no count property. Jopr takes this from ProfilseService, so perhaps that's where zero comes from? Anyway, this is a regression.

  was:
After sending a message(s), the some properties have bad values:

Count = 0,
Count Delta = 0,
Time Last Update = 0,

However, 

Depth	4	The current message count of pending messages within the queue waiting for dispatch
Depth Delta	3	The message count delta of pending messages since last method call

Did the meaning of  Count change?

I've looked at the queue MBean in JMX console, and there's no count property. Jopr takes this from ProfilseService, so perhaps that's where zero comes from? Anyway, this is a regression.



> JMS Destinations: properties "Count" and "Time Last Update" are 0 after sending a message
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-7125
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7125
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (JBoss Messaging), ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: Tests:
> testQueueMetrics*
> testTopicMetrics*
>            Reporter: Ondrej ?i?ka
>            Assignee: Scott M Stark
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> After sending a message(s), some properties have bad values:
> Count = 0,
> Count Delta = 0,
> Time Last Update = 0,
> However, 
> Depth	4	The current message count of pending messages within the queue waiting for dispatch
> Depth Delta	3	The message count delta of pending messages since last method call
> Did the meaning of  Count change?
> I've looked at the queue MBean in JMX console, and there's no count property. Jopr takes this from ProfilseService, so perhaps that's where zero comes from? Anyway, this is a regression.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Tue Jul 28 10:36:30 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 28 Jul 2009 10:36:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1550) Core
 BridgeConfiguration with a discovery group is not deployed
In-Reply-To: <22813655.1237480462871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1780929951.1248791790286.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned JBMESSAGING-1550:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> Core BridgeConfiguration with a discovery group is not deployed
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1550
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1550
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> A Core BridgeConfiguration can be set with either a discovery group or a pair of connectors.
> When the bridge is deployed (in ClusterManager.start()), we only check for the pair of connectors.
> If the bridge config uses a discovery group, it will never be deployed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 11:56:42 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Udo_Klinkm=C3=BCller_=28JIRA=29?=)
Date: Tue, 28 Jul 2009 11:56:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2218) Unknown error
 while parsing. This is a bug. Please contact the Development team.
Message-ID: <1817292291.1248796602094.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Unknown error while parsing. This is a bug. Please contact the Development team.
--------------------------------------------------------------------------------

                 Key: JBRULES-2218
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2218
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-eclipse
    Affects Versions: 5.0.0.FINAL
         Environment: Eclipse 3.5 (Galileo), Mac OS X
            Reporter: Udo Klinkm?ller
            Assignee: Mark Proctor


rule "Arrival-Delayed-Upd"
	salience 1000 
	when
		#conditions
		VisitPair( $ov: oldVisit != null, $nv: visit )
		$oaf: ArrivalFlight( onBlock == null, $ost: scheduledTime != null, $op: position != null ) from $ov.arrivalFlight
		$naf: ArrivalFlight( onBlock == null, (($nst: scheduledTime != null, != $ost) || ($np: position != null, != $op)) ) from $nv.arrivalFlighT
		
	then 
		#actions
		Date vf = addMinutes($nst, 15); 
		ResourceEvent re = eventBuilderFactory.getResourceVisitEventBuilder(EventType.ARRIVAL_DELAYED, $naf.getPositionKey(), vf)
			.visitKey($nv.getKey())
			.build();
		eventHandler.handleEvent(re);
end

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Tue Jul 28 14:59:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 28 Jul 2009 14:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7127) Upgrade JBoss JAXR
	to 2.0.0
Message-ID: <211516475.1248807569127.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade JBoss JAXR to 2.0.0
---------------------------

                 Key: JBAS-7127
                 URL: https://jira.jboss.org/jira/browse/JBAS-7127
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JAXR service
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: JBossAS-5.2.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 15:03:41 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 28 Jul 2009 15:03:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7127) Upgrade JBoss JAXR to
	2.0.0
In-Reply-To: <211516475.1248807569127.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1581925247.1248807821701.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBAS-7127.
-------------------------------

    Resolution: Done


anil at localhost:~/Branch_5_x$ svn ci -m "JBAS-7127: upgrade to JBoss JAXR 2.0.0" component-matrix/ testsuite/
Sending        component-matrix/pom.xml
Sending        testsuite/build.xml
Transmitting file data ..
Committed revision 91733.
anil at localhost:~/Branch_5_x$

> Upgrade JBoss JAXR to 2.0.0
> ---------------------------
>
>                 Key: JBAS-7127
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7127
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JAXR service
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 15:05:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 28 Jul 2009 15:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7128) JBoss 5.2.0
 Testsuite Failures Container Task
Message-ID: <827670661.1248807929533.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss 5.2.0 Testsuite Failures Container Task
---------------------------------------------

                 Key: JBAS-7128
                 URL: https://jira.jboss.org/jira/browse/JBAS-7128
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Anil Saldhana
            Assignee: Shelly McGowan
             Fix For: JBossAS-5.2.0.Beta1


Container Task for JBoss 5.2.0 Test Suite Failures.  Mainly for Branch_5_x.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 15:07:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 28 Jul 2009 15:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7129) Test Target
 tests-scout-jaxr failures
Message-ID: <860108443.1248808049353.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Test Target tests-scout-jaxr failures
-------------------------------------

                 Key: JBAS-7129
                 URL: https://jira.jboss.org/jira/browse/JBAS-7129
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JAXR service, Test Suite
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: JBossAS-5.2.0.Beta1




==============
tests-scout-jaxr:
    [mkdir] Created dir: /home/anil/Branch_5_x/testsuite/output/log
    [junit] Running org.jboss.test.jaxr.scout.JaxrBaseTestCase     
    [junit] Running org.jboss.test.jaxr.scout.JaxrBaseTestCase     
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.685 sec
    [junit] Running org.jboss.test.jaxr.scout.basic.JaxrJNDIConnectionTestCase
    [junit] Running org.jboss.test.jaxr.scout.basic.JaxrJNDIConnectionTestCase
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.354 sec     
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase
    [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 4.051 sec          
    [junit] Test org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase FAILED
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteOrganizationTestCase   
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteOrganizationTestCase   
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.898 sec              
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveOrganizationTestCase     
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveOrganizationTestCase     
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.687 sec              
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveServiceBindingTestCase   
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveServiceBindingTestCase   
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.705 sec              
    [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase
    [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase
    [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 2.193 sec                
    [junit] Test org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase FAILED
    [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrConfimAssociationTestCase
    [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrConfimAssociationTestCase
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.265 sec                    
    [junit] Running org.jboss.test.jaxr.scout.query.JaxrBusinessQueryTestCase                
    [junit] Running org.jboss.test.jaxr.scout.query.JaxrBusinessQueryTestCase                
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.187 sec                    
    [junit] Running org.jboss.test.jaxr.scout.query.infomodel.JaxrFindAssociationsTestCase   
    [junit] Running org.jboss.test.jaxr.scout.query.infomodel.JaxrFindAssociationsTestCase   
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.505 sec    
==================================

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 16:56:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Tue, 28 Jul 2009 16:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-1139) Modify PortUtil
 to allow a configurable range for MIN_UNPRIVILEGED_PORT and MAX_LEGAL_PORT.
In-Reply-To: <215395097.1246517211483.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2143727278.1248814589507.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBREM-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477964#action_12477964 ] 

Ron Sigal commented on JBREM-1139:
----------------------------------

The range from which PortUtil will choose ports may now be modified per JVM.

The parameters

 org.jboss.remoting.transport.PortUtil.MIN_PORT (actual value "minPort")
 org.jboss.remoting.transport.PortUtil.MAX_PORT (actual value "maxPort")

can be added to

 (1) the InvokerLocator,
 (2) a configuration map passed to org.jboss.remoting.Client or org.jboss.remoting.transport.Connector, or
 (3) the Connector's MBean definition

and they will be used to set the range used by PortUtil (determined by PortUtil.minPort and PortUtil.maxPort).  Note that PortUtil.minPort and PortUtil.maxPort are static values, so setting them affects all other clients and servers in the JVM.  Also, the values will be updated only if the resulting range is more restrictive.  I.e.,

 PortUtil.minPort == 3000  and  PortUtil.maxPort == 50000

can be updated to

 PortUtil.minPort == 4000  and  PortUtil.maxPort == 40000

but not to

 PortUtil.minPort == 2000 and  PortUtil.maxPort == 60000.

So far, the changes have been added to branch 2.2.  As usual in Remoting 2.2.x, the values in InvokerLocator take precedence over the values in the configuration map.

Unit tests:

  * org.jboss.test.remoting.util.PortUtilRangeOnClientTestCase
  * org.jboss.test.remoting.util.PortUtilRangeOnServerTestCase
  * org.jboss.test.remoting.util.PortUtilRangeOnServerWithXMLTestCase

Still have to apply changes to branch 2.x.

> Modify PortUtil to allow a configurable range for MIN_UNPRIVILEGED_PORT and MAX_LEGAL_PORT.
> -------------------------------------------------------------------------------------------
>
>                 Key: JBREM-1139
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1139
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.5.1 (Flounder), 2.2.3
>            Reporter: Colin Mondesir
>            Assignee: Ron Sigal
>             Fix For: 2.5.2 (Flounder), 2.2.3.SP1
>
>
> PortUtil could be improved to read the port range configuration.
> This is straightforward and no side effect is expected.  However,
> PortUtil and its callers will need some refactoring as it is just a
> static utility classes currently.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 17:00:29 2009
From: jira-events at lists.jboss.org (Ron Sigal (JIRA))
Date: Tue, 28 Jul 2009 17:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-1143) CLONE [JBREM-877]
 - New Socket Connection is being Created for Every Client Request to the
 Server
In-Reply-To: <1703765675.1247253809257.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1458387550.1248814829313.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBREM-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12477969#action_12477969 ] 

Ron Sigal commented on JBREM-1143:
----------------------------------

The changes have been  applied to the 2.2 branch.

Unit test:  org.jboss.test.remoting.invoke.ClientInvokerDelayedDestructionTestCase

Waiting for results in test suite.

> CLONE [JBREM-877] - New Socket Connection is being Created for Every Client Request to the Server
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBREM-1143
>                 URL: https://jira.jboss.org/jira/browse/JBREM-1143
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 2.2.3
>            Reporter: Kumarselvan Somasundaram
>            Assignee: Ron Sigal
>             Fix For: 2.2.3.SP1
>
>
> JBREM-877 is being cloned to port the feature back to the 2.2 branch.  The original description:
> whenever  EJB3 client requests the Server new socket is being created. at the client side the socket connection pool is not being used. Hope there is some issue with the socket connection after getting response from the server,becoz of which the server side the connection is being closed. this increases the CPU utilization,
> The same code is running fine in jboss 4.0.4 with jboss remoting 1.4.0
> new remoting 2.2.2 SP4 only handling 1/4 of the load with high CPU utilization. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 18:49:29 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 28 Jul 2009 18:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (RELOADED-9) JNDI standardized
	namespaces
Message-ID: <907973659.1248821369136.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JNDI standardized namespaces
----------------------------

                 Key: RELOADED-9
                 URL: https://jira.jboss.org/jira/browse/RELOADED-9
             Project: JBoss Reloaded
          Issue Type: Feature Request
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 20:22:42 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 28 Jul 2009 20:22:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7130) Stack trace when
 starting up "all" configuration
Message-ID: <1446554410.1248826962724.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Stack trace when starting up "all" configuration
------------------------------------------------

                 Key: JBAS-7130
                 URL: https://jira.jboss.org/jira/browse/JBAS-7130
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JSF, Web (Tomcat) service
            Reporter: David Lloyd
            Assignee: Stan Silvert
             Fix For: JBossAS-6.0.0.Alpha1


I get the following stack trace when starting up in the "all" configuration:

19:19:07,154 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
19:19:07,187 WARNING [config] Unable to process deployment descriptor for context '/invoker': java.lang.IllegalArgumentException: InputStream cannot be null
	at javax.xml.parsers.SAXParser.parse(SAXParser.java:194)
	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.scanForFacesServlet(ConfigureListener.java:752)
	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.<init>(ConfigureListener.java:712)
	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:165)
	at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:60)
	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393)
	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
	at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:462)
	at org.jboss.web.deployers.WebModule.startModule(WebModule.java:116)
	at org.jboss.web.deployers.WebModule.start(WebModule.java:95)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
	at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:207)
	at $Proxy38.start(Unknown Source)
	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
	at org.jboss.system.ServiceController.start(ServiceController.java:443)
	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
	at org.jboss.system.ServiceController.start(ServiceController.java:443)
	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.system.ServiceController.doInstall(ServiceController.java:653)
	at org.jboss.system.ServiceController.register(ServiceController.java:356)
	at org.jboss.system.microcontainer.jmx.ServiceControllerRegistrationLifecycleCallback.install(ServiceControllerRegistrationLifecycleCallback.java:104)
	at sun.reflect.GeneratedMethodAccessor239.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
	at org.jboss.system.ServiceController.start(ServiceController.java:443)
	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 20:39:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 28 Jul 2009 20:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBLOGGING-22) Log file is
 randomly truncated when configured from JBossMC/JBossAS
In-Reply-To: <30688019.1248726089233.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1069168884.1248827969291.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBLOGGING-22.
--------------------------------

    Resolution: Done


> Log file is randomly truncated when configured from JBossMC/JBossAS
> -------------------------------------------------------------------
>
>                 Key: JBLOGGING-22
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-22
>             Project: JBoss Logging
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logmanager
>    Affects Versions: 1.1.0.CR4-jboss-logmanager
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 1.1.0.CR5-jboss-logmanager
>
>
> Due to strangeness in the way that JBossMC's BeanMetaDataBuilder.addProperty() method works, the file name of the rotating file handlers is sometimes (but not always) set before the append flag, causing the file to be truncated even if append was set to true.
> Add constructors such that both properties can be set simultaneously to work around this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 21:36:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 28 Jul 2009 21:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-23) Add support for
 internationalization and localization with parameterized messages
Message-ID: <731548133.1248831389259.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add support for internationalization and localization with parameterized messages
---------------------------------------------------------------------------------

                 Key: JBLOGGING-23
                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-23
             Project: JBoss Logging
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: jboss-logging-jdk, jboss-logging-log4j, jboss-logging-spi
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 2.2.0.CR1-jboss-logging


The logging API should support optional parameters E.g.:

    /**
     * Issue a log message with parameters and a throwable with a level of TRACE.
     *
     * @param loggerFqcn the logger class name
     * @param message the message
     * @param params the message parameters
     * @param t the throwable
     */
   public void trace(String loggerFqcn, Object message, Object[] params, Throwable t) { ... }

The logger factory method should allow specification of a resource bundle, e.g.:

   Logger getLogger(String category, String resourceBundleName) { ... }


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Jul 28 21:38:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 28 Jul 2009 21:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-24) Add ability to
 cache logger instances
Message-ID: <109580682.1248831509140.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add ability to cache logger instances
-------------------------------------

                 Key: JBLOGGING-24
                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-24
             Project: JBoss Logging
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: jboss-logging-jdk, jboss-logging-log4j, jboss-logging-spi
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 2.2.0.CR1-jboss-logging


The present API/SPI does not allow logger instances to be cached and reused, which can cause unnecessary memory pressure by creating many identical objects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 02:10:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 29 Jul 2009 02:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1649489172.1248847829251.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478012#action_12478012 ] 

Howard Gao commented on JBMESSAGING-1685:
-----------------------------------------

Hi Martin,

If I didn't understand wrong, the problem is that there is too much messages in the DLQ and this caused OOM. The DLQ is just like any other queues in JBM, which will holds messages that are sent to it. To control the memory usage of a queue, you can limit the number of messages that reside in memory by specifying fullSize/pageSize/downCacheSize attributes of the queue. Any more messages that exceed the fullSize will be stored to DB and later will be loaded as the messages are being delivered off. 

The properties are described in the JBM doc. Please try it and see if the OOM is gone.

> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java, QueueExampleLong.java, QueueExampleLong2.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 03:15:29 2009
From: jira-events at lists.jboss.org (Bernard de Terwangne (JIRA))
Date: Wed, 29 Jul 2009 03:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2436) JBPC 2.0 :
 ResourceResponse.setCharacterEncoding always throws
 UnsupportedOperationException
Message-ID: <663297249.1248851729342.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBPC 2.0 : ResourceResponse.setCharacterEncoding always throws UnsupportedOperationException
--------------------------------------------------------------------------------------------

                 Key: JBPORTAL-2436
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2436
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: Portlet-2.0
         Environment: Any
            Reporter: Bernard de Terwangne


package org.jboss.portal.portlet.impl.jsr168.api;

...

public class ResourceResponseImpl extends MimeResponseImpl implements ResourceResponse
{
...
   public void setLocale(Locale locale)
   {
      throw new UnsupportedOperationException();
   }

   public void setCharacterEncoding(String s)
   {
      throw new UnsupportedOperationException();
   }

   public void setContentLength(int i)
   {
      throw new UnsupportedOperationException();
   }

...
}

Problems come when you want to deploy your portlet on JBoss PortletContainer and on other portals. JSR-286 does not state that portals my throw UnsupportedOperationException.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 04:57:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Wed, 29 Jul 2009 04:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-113) Support standard
 303 validation annotation
In-Reply-To: <713920493.1247472449189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2076600072.1248857849139.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved JBJCA-113.
------------------------------

    Resolution: Done


> Support standard 303 validation annotation
> ------------------------------------------
>
>                 Key: JBJCA-113
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-113
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> *) ra16standard303.rar (Valid (@NotNull) - must be deployed)
> Create a resource adapter in deployer/test that uses standard 303 defined 
> tags like @NotNull and @Min

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 05:01:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Wed, 29 Jul 2009 05:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-114) Support custom 303
 validation annotation
In-Reply-To: <940958141.1247472580910.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1139792308.1248858089296.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved JBJCA-114.
------------------------------

    Resolution: Done


> Support custom 303 validation annotation
> ----------------------------------------
>
>                 Key: JBJCA-114
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-114
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> *) ra16user303.rar (Valid (@FrenchZipcode) - must be deployed)
> Create a resource adapter in deployer/test that uses custom defined tags - 
> an example would be @FrenchZipcode from the 303 spec. The resource adapter 
> must of course include the classes needed to make this happen

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 05:01:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Wed, 29 Jul 2009 05:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-116) Negative test for
 custom 303 validation annotation
In-Reply-To: <673733390.1247472809337.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <153965379.1248858089386.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved JBJCA-116.
------------------------------

    Resolution: Done


> Negative test for custom 303 validation annotation
> --------------------------------------------------
>
>                 Key: JBJCA-116
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-116
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> ra16user303jbossra.rar (Invalid - must fail)
> define in ra.xml and override in jboss-ra.xml, validate should be fail

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 05:01:29 2009
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Wed, 29 Jul 2009 05:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-115) Negative test for
 standard 303 validation annotation
In-Reply-To: <1562454476.1247472809212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1172956974.1248858089480.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved JBJCA-115.
------------------------------

    Resolution: Done


> Negative test for standard 303 validation annotation
> ----------------------------------------------------
>
>                 Key: JBJCA-115
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-115
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> ra16standard303jbossra.rar (Invalid - must fail)
> define in ra.xml and override in jboss-ra.xml, validate should be fail

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 05:40:29 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 29 Jul 2009 05:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-70) Allow multiple
 @Management interfaces for a @Service bean
Message-ID: <58351899.1248860429777.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved EJBTHREE-70.
-----------------------------------

    Resolution: Won't Fix
      Assignee: Carlo de Wolf  (was: Bill Burke)


> Allow multiple @Management interfaces for a @Service bean
> ---------------------------------------------------------
>
>                 Key: EJBTHREE-70
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-70
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: Preview 3
>            Reporter: Kabir Khan
>            Assignee: Carlo de Wolf
>
> See http://jira.jboss.com/jira/browse/EJBTHREE-65

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 06:07:29 2009
From: jira-events at lists.jboss.org (Martin Putz (JIRA))
Date: Wed, 29 Jul 2009 06:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2437) Remove
 hard-coded context path references
Message-ID: <1997590605.1248862049393.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Remove hard-coded context path references
-----------------------------------------

                 Key: JBPORTAL-2437
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2437
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.7.2 Final
            Reporter: Martin Putz
            Assignee: Thomas Heute


All portal contexts should be configurable to share a common context. For this to work, we customized our jboss portal installation changing the context path. We modified following files:

./portal-admin.sar/portal-admin.war/WEB-INF/jboss-web.xml
./portal-ajax.war/WEB-INF/jboss-web.xml
./portal-cms.sar/portal-cms.war/WEB-INF/jboss-web.xml
./portal-core.war/WEB-INF/jboss-web.xml
./portal-identity.sar/portal-identity.war/WEB-INF/jboss-web.xml
./portal-server.war/WEB-INF/jboss-web.xml
./portal-widget-netvibes.war/WEB-INF/jboss-web.xml
./portal-widget.war/WEB-INF/jboss-web.xml
./portal-wsrp.sar/portal-wsrp-admin.war/WEB-INF/jboss-web.xml
./portal-wsrp.sar/portal-wsrp.war/WEB-INF/jboss-web.xml
./samples/portal-jsp-samples.war/WEB-INF/jboss-web.xml
./samples/portal-news-samples.war/WEB-INF/jboss-web.xml
./samples/portal-portlet-samples.war/WEB-INF/jboss-web.xml
./samples/portal-users-samples.sar/portal-users-samples.war/WEB-INF/jboss-web.xml

For example, the file ./portal-admin.sar/portal-admin.war/WEB-INF/jboss-web.xml has been modified in the following way:

<jboss-web>
       <context-root>/portal/portal-admin</context-root>
</jboss-web>

The file ./portal-core.war/WEB-INF/jboss-web.xml became:

<jboss-web>
       <context-root>/portal/portal-core</context-root>
</jboss-web>

As the default context names are hard-coded in some references, a couple of links are corrupted like this:

<img src="/portal-core/images/portletIcon_Default1.gif" alt="icon" align="middle" style="margin:0 4px 0 0" />

The context path should not be hard-coded in the sources.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 07:40:29 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Wed, 29 Jul 2009 07:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
In-Reply-To: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2099188738.1248867629815.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1693:
--------------------------------------

    Attachment: JMSConsumer.java


> Unable to consume more than  777,000 messages
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1693
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>         Environment: Windows Vista, 32 bit, 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>            Priority: Critical
>         Attachments: JMSBase.java, JMSConsumer.java, JMSSender.java, src.rar, TestCunsumer.java, TestSender.java
>
>
> Using messaging-2.0.0.BETA3 stand alone non-clustered
> -------------------------------------------------------------------------------
> I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
>  <global-page-size>10485760</global-page-size>
> <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 
> Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
> -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
> Please find the attached java files. Test instructions are given below
> 1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
> 2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
> 3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
> 4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
> 5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
> Messages Consumed = messagesAdded -  MessageCount  
>  a) 800246 - 23246 = 777000
>  b) 799037 - 22037 = 777000
>  c)  799037 - 22037 = 777000
> It seems the number of messages consumed (777000 in above case) is driven by message size (and Queue size).  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 07:40:29 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Wed, 29 Jul 2009 07:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
In-Reply-To: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <224204782.1248867629647.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1693:
--------------------------------------

    Attachment: JMSBase.java


> Unable to consume more than  777,000 messages
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1693
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>         Environment: Windows Vista, 32 bit, 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>            Priority: Critical
>         Attachments: JMSBase.java, JMSConsumer.java, JMSSender.java, src.rar, TestCunsumer.java, TestSender.java
>
>
> Using messaging-2.0.0.BETA3 stand alone non-clustered
> -------------------------------------------------------------------------------
> I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
>  <global-page-size>10485760</global-page-size>
> <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 
> Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
> -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
> Please find the attached java files. Test instructions are given below
> 1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
> 2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
> 3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
> 4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
> 5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
> Messages Consumed = messagesAdded -  MessageCount  
>  a) 800246 - 23246 = 777000
>  b) 799037 - 22037 = 777000
>  c)  799037 - 22037 = 777000
> It seems the number of messages consumed (777000 in above case) is driven by message size (and Queue size).  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 07:40:29 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Wed, 29 Jul 2009 07:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
In-Reply-To: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <633735148.1248867629944.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1693:
--------------------------------------

    Attachment: JMSSender.java


> Unable to consume more than  777,000 messages
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1693
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>         Environment: Windows Vista, 32 bit, 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>            Priority: Critical
>         Attachments: JMSBase.java, JMSConsumer.java, JMSSender.java, src.rar, TestCunsumer.java, TestSender.java
>
>
> Using messaging-2.0.0.BETA3 stand alone non-clustered
> -------------------------------------------------------------------------------
> I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
>  <global-page-size>10485760</global-page-size>
> <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 
> Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
> -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
> Please find the attached java files. Test instructions are given below
> 1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
> 2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
> 3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
> 4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
> 5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
> Messages Consumed = messagesAdded -  MessageCount  
>  a) 800246 - 23246 = 777000
>  b) 799037 - 22037 = 777000
>  c)  799037 - 22037 = 777000
> It seems the number of messages consumed (777000 in above case) is driven by message size (and Queue size).  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 07:40:30 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Wed, 29 Jul 2009 07:40:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
In-Reply-To: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <773841589.1248867630098.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1693:
--------------------------------------

    Attachment: TestCunsumer.java


> Unable to consume more than  777,000 messages
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1693
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>         Environment: Windows Vista, 32 bit, 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>            Priority: Critical
>         Attachments: JMSBase.java, JMSConsumer.java, JMSSender.java, src.rar, TestCunsumer.java, TestSender.java
>
>
> Using messaging-2.0.0.BETA3 stand alone non-clustered
> -------------------------------------------------------------------------------
> I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
>  <global-page-size>10485760</global-page-size>
> <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 
> Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
> -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
> Please find the attached java files. Test instructions are given below
> 1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
> 2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
> 3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
> 4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
> 5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
> Messages Consumed = messagesAdded -  MessageCount  
>  a) 800246 - 23246 = 777000
>  b) 799037 - 22037 = 777000
>  c)  799037 - 22037 = 777000
> It seems the number of messages consumed (777000 in above case) is driven by message size (and Queue size).  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 07:40:30 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Wed, 29 Jul 2009 07:40:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1693) Unable to
 consume more than 777, 000 messages
In-Reply-To: <1303462536.1248754469182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <433037665.1248867630223.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1693:
--------------------------------------

    Attachment: TestSender.java


> Unable to consume more than  777,000 messages
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1693
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1693
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>         Environment: Windows Vista, 32 bit, 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>            Priority: Critical
>         Attachments: JMSBase.java, JMSConsumer.java, JMSSender.java, src.rar, TestCunsumer.java, TestSender.java
>
>
> Using messaging-2.0.0.BETA3 stand alone non-clustered
> -------------------------------------------------------------------------------
> I am trying to consume 1 Million messages from a Queue using 10 concurrent consumers (Threads) . Consumption hangs after consuming 777,000 messages.  i.e. even though I am able to see the messages from JConsole, Consumers does not read any. Below given are the memory settings for the Queue
>  <global-page-size>10485760</global-page-size>
> <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 
> Also, I have added the following JVM parameters in run.bat script to enable JMX. Rest of the configuration files are untouched (i.e. they are with default settings)
> -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
> Please find the attached java files. Test instructions are given below
> 1) Execute "TestSender.java" and let it complete. This will send 1 million messages to Queue "myQQ".
> 2) Observe the Queue "myQQ" from JConsole. It can be seen that there are 23745 messages in Queue (means rest are paged).
> 3) Execute "TestCunsumer.java". This will spawn 10 consumer threads to read from "myQQ"
> 4) Observe from JConsole that the messages are getting consumed. i.e. values of MessageCount and MessageAdded attributes keeps on changing
> 5) Observe that after a while, consumption hangs (i.e.values of MessageCount and MessageAdded attributes does not change). I calculated the number of messages consumed by subtracting MessageCount  from messagesAdded. Following are the values I got for last three runs
> Messages Consumed = messagesAdded -  MessageCount  
>  a) 800246 - 23246 = 777000
>  b) 799037 - 22037 = 777000
>  c)  799037 - 22037 = 777000
> It seems the number of messages consumed (777000 in above case) is driven by message size (and Queue size).  Because, when I tried another message, the consumption hanged after 780,000 messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 08:14:29 2009
From: jira-events at lists.jboss.org (Aleksander Adamowski (JIRA))
Date: Wed, 29 Jul 2009 08:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (BPEL-307) Migrate CVS source
 repository to SVN
Message-ID: <1671862215.1248869669304.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Migrate CVS source repository to SVN
------------------------------------

                 Key: BPEL-307
                 URL: https://jira.jboss.org/jira/browse/BPEL-307
             Project: JBoss jBPM BPEL
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Aleksander Adamowski
            Assignee: Alejandro Guizar


The jBPM-BPEL sources are hard to find because, unlike almost all other JBoss projects (including jBPM), they are not hosted in SVN on the main JBoss server (http://svn.jboss.org/repos/).


The page http://jboss.org/jbossjbpm/bpel_sources/ gives info about how to check out the sources from CVS.

However, this requires outgoing access to port 2401 and from some firewalled environtments where outside access is only possible through a HTTP proxy the CVS repository is inaccessible. Also, CVS is a version control system vastly inferior to SVN.

Therefore, JBoss jBPM-BPEL source repository should be migrated to SVN.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 08:32:29 2009
From: jira-events at lists.jboss.org (Daniel Bevenius (JIRA))
Date: Wed, 29 Jul 2009 08:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7132)
 shutdown.sh/shutdown.bat is missing jars in its classpath which causes
 NoClassDefFoundError(s)
Message-ID: <1226982325.1248870749134.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

shutdown.sh/shutdown.bat is missing jars in its classpath which causes NoClassDefFoundError(s) 
-----------------------------------------------------------------------------------------------

                 Key: JBAS-7132
                 URL: https://jira.jboss.org/jira/browse/JBAS-7132
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Daniel Bevenius
            Priority: Minor


Currently the server/src/bin/shutdown.sh contains only two jars:
JBOSS_BOOT_CLASSPATH="$JBOSS_HOME/bin/shutdown.jar:$JBOSS_HOME/client/jbossall-client.jar"
and as far as I can tell it requires:
JBOSS_BOOT_CLASSPATH="$JBOSS_HOME/bin/shutdown.jar:$JBOSS_HOME/client/jbossall-client.jar:$JBOSS_HOME/lib/jboss-bootstrap-spi-as.jar:$JBOSS_HOME/lib/jboss-bootstrap-spi-mc.jar:$JBOSS_HOME/lib/jboss-bootstrap-spi.jar:$JBOSS_HOME/lib/jboss-system-jmx.jar:$JBOSS_HOME/lib/jboss-kernel.jar"

If you like feel free to assign this to me.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 08:49:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 29 Jul 2009 08:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1016) memory leak in GMS
	protocol
In-Reply-To: <1523793676.1248774569291.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <196368678.1248871769182.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1016:
---------------------------

    Fix Version/s: 2.6.11
                   2.8
         Priority: Major  (was: Critical)


> memory leak in GMS protocol
> ---------------------------
>
>                 Key: JGRP-1016
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1016
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>            Reporter: Miro Selent
>            Assignee: Bela Ban
>             Fix For: 2.6.11, 2.8
>
>
> Found in org.jgroups.protocols.pbcast.GMS in a scenario where members were killed and restarted very frequently and one member is persistently running. The memory consumption icreased very quickly until OutOfMemory.
> Our analysis with JProfiler leads to the following assumption:
> The number of org.jgroups.stack.IpAddress held by merge_ack_collector icreases every time a member was (re)started. 
> These instances were never removed because no MERGE events occured. This is completely clear since there was only one coordinator (the long running member). 
> If GMS receives no MERGE event it never cleans up the stored IpAddress instances in the merge_ack_collector.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 09:50:29 2009
From: jira-events at lists.jboss.org (Thomas Heute (JIRA))
Date: Wed, 29 Jul 2009 09:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-2356) It is
 impossible to use html forms in portlets or js to build http request
In-Reply-To: <10202950.1238084123266.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <723706396.1248875429466.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBPORTAL-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478064#action_12478064 ] 

Thomas Heute commented on JBPORTAL-2356:
----------------------------------------

In order to apply your patch I would need you to sign the contributor agreement if possible:
https://www.jboss.org/contribute/

Thanks !

> It is impossible to use html forms in portlets or js to build http request
> --------------------------------------------------------------------------
>
>                 Key: JBPORTAL-2356
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2356
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: Portlet-2.0.1
>         Environment: Linux, Java 5, Tomcat, JBoss Portlet Container 2.0
>            Reporter: Bernard de Terwangne
>         Attachments: ControllerRequestFactory.java, ControllerRequestFactory.java, ControllerRequestFactoryTestCase.java
>
>
> JBoss Portlet container conforms to the spec so well that it becomes unusable. It is impossible to query the end-user for a value and pass that value in processAction or serveResource calls. Let's say you write this in your JSP page :
> <form action="<portlet:actionURL><portlet:param name='q' value='yop'/></portlet:actionURL">
> <input name="q" type="text/>
> <input type="submit"/>
> </form>
> and in the Java code
> 	public void processAction(ActionRequest req, ActionResponse res)
> 			throws IOException, PortletException {
> 		System.out.println(req.getParameter("q");
>         }
> The printed value will allways be "yop" (the value placed in the portlet:param tag. There is no way to retrieve the value actually typed by the end user.
> This is due to the fact JBoss Portlet container mangles in Base64 the parameters from <portlet:param> and disregards parameters appended by the browser's form implementation. Same thing with <resourceURL>. There is no way to pass user input to the portlet's Java code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 10:06:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 10:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-130) SJC: Wrap all
 deployment exceptions in DeployException
Message-ID: <1971953316.1248876389209.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC: Wrap all deployment exceptions in DeployException
------------------------------------------------------

                 Key: JBJCA-130
                 URL: https://jira.jboss.org/jira/browse/JBJCA-130
             Project: JBoss JCA
          Issue Type: Task
          Components: Standalone
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 10:06:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 10:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-130) SJC: Wrap all
 deployment exceptions in DeployException
In-Reply-To: <1971953316.1248876389209.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1959391779.1248876389284.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-130.
-----------------------------------

    Resolution: Done


> SJC: Wrap all deployment exceptions in DeployException
> ------------------------------------------------------
>
>                 Key: JBJCA-130
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-130
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Standalone
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 10:48:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 10:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-118) SJC/RADeployer:
 Merge specification and vendor metadata
In-Reply-To: <369789920.1247765680901.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <906542183.1248878909796.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-118.
-----------------------------------

    Resolution: Done


> SJC/RADeployer: Merge specification and vendor metadata
> -------------------------------------------------------
>
>                 Key: JBJCA-118
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-118
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Merge the metadata from the specification (ConnectorMetaData) with our metadata (JBossRAMetaData).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 10:52:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 10:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-102) SJC/RADeployer:
 Merge annotations and metadata
In-Reply-To: <2016998490.1246458231392.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <973935655.1248879149231.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-102:
----------------------------------

    Fix Version/s: 1.0.0.Alpha3
                       (was: 1.0.0.Alpha2)


> SJC/RADeployer: Merge annotations and metadata
> ----------------------------------------------
>
>                 Key: JBJCA-102
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-102
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Deployer
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha3
>
>
> Merge the metadata from the XML and the annotations into a single model.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 10:52:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 10:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-123) Update logging
	framework
In-Reply-To: <1781074719.1248718062317.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <251184603.1248879149381.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-123.
-----------------------------------

    Resolution: Done


> Update logging framework
> ------------------------
>
>                 Key: JBJCA-123
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-123
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Build, Standalone
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Update the logging framework to use JBoss LogManager 1.1 and dependant libraries.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 11:53:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 29 Jul 2009 11:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6918) "trackByTxn"
 always gets displayed as "false" in the output of the "listStatistics"
 operation for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <552196278.1248882809818.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478095#action_12478095 ] 

Ian Springer commented on JBAS-6918:
------------------------------------

Note, I think the "track-connection-by-tx" prop is deprecated, at least in some cases (see https://jira.jboss.org/jira/browse/JBAS-5203).


> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 11:53:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Jul 2009 11:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1601) Cache Large
 Message body on Client
In-Reply-To: <12004607.1239904702467.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <951643740.1248882809931.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1601:
-----------------------------------------

       Summary: Cache Large Message body on Client  (was: JMSBridge won't work with LargeMessages and resend)
    Issue Type: Feature Request  (was: Bug)


> Cache Large Message body on Client
> ----------------------------------
>
>                 Key: JBMESSAGING-1601
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1601
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> The JMS Bridge is caching a Message, and resending it when a failure occurs.
> On the case of a LargeMessage, the message should be received again instead of cached.
> Actually caching won't work with LargeMessages at all.
> There should be a config on JMSBridge that would complete disable caching, and the message would be received again in case of failure on either side (src or dest address). The user would need then to configure the JMSBridge accordingly to LargeMessages if that feature is being used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 11:53:30 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Jul 2009 11:53:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1601) Cache Large
 Message body on Client
In-Reply-To: <12004607.1239904702467.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1230533959.1248882810068.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1601.
----------------------------------------

    Resolution: Done


> Cache Large Message body on Client
> ----------------------------------
>
>                 Key: JBMESSAGING-1601
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1601
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> The JMS Bridge is caching a Message, and resending it when a failure occurs.
> On the case of a LargeMessage, the message should be received again instead of cached.
> Actually caching won't work with LargeMessages at all.
> There should be a config on JMSBridge that would complete disable caching, and the message would be received again in case of failure on either side (src or dest address). The user would need then to configure the JMSBridge accordingly to LargeMessages if that feature is being used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 11:59:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Wed, 29 Jul 2009 11:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6918) "trackByTxn"
 always gets displayed as "false" in the output of the "listStatistics"
 operation for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1582973289.1248883169491.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478098#action_12478098 ] 

Charles Crouch commented on JBAS-6918:
--------------------------------------

Jason to determine whether "track-connection-by-tx" is deprecated or not.
One option is just to drop the "trackByTxn" property from the operation

> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 11:59:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Wed, 29 Jul 2009 11:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6918) "trackByTxn" always
 gets displayed as "false" in the output of the "listStatistics" operation
 for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <47265925.1248883169661.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch reassigned JBAS-6918:
------------------------------------

    Assignee: Jason T. Greene  (was: Scott M Stark)


> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Jason T. Greene
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:01:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-131) SJC: Create resource
 adapter object
Message-ID: <1786446646.1248886889184.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SJC: Create resource adapter object
-----------------------------------

                 Key: JBJCA-131
                 URL: https://jira.jboss.org/jira/browse/JBJCA-131
             Project: JBoss JCA
          Issue Type: Task
          Components: Standalone
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha2


Create the resource adapter object and inject all its property values.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:03:41 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:03:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-131) SJC: Create
 resource adapter object
In-Reply-To: <1786446646.1248886889184.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1009696296.1248887021035.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-131.
-----------------------------------

    Resolution: Done


> SJC: Create resource adapter object
> -----------------------------------
>
>                 Key: JBJCA-131
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-131
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Standalone
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Create the resource adapter object and inject all its property values.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:07:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 13:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7129) Test Target
 tests-scout-jaxr failures
In-Reply-To: <860108443.1248808049353.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <245439249.1248887249168.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478105#action_12478105 ] 

Anil Saldhana commented on JBAS-7129:
-------------------------------------

Dependent on the fix of https://issues.apache.org/jira/browse/SCOUT-88

> Test Target tests-scout-jaxr failures
> -------------------------------------
>
>                 Key: JBAS-7129
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7129
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JAXR service, Test Suite
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> ==============
> tests-scout-jaxr:
>     [mkdir] Created dir: /home/anil/Branch_5_x/testsuite/output/log
>     [junit] Running org.jboss.test.jaxr.scout.JaxrBaseTestCase     
>     [junit] Running org.jboss.test.jaxr.scout.JaxrBaseTestCase     
>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.685 sec
>     [junit] Running org.jboss.test.jaxr.scout.basic.JaxrJNDIConnectionTestCase
>     [junit] Running org.jboss.test.jaxr.scout.basic.JaxrJNDIConnectionTestCase
>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.354 sec     
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase
>     [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 4.051 sec          
>     [junit] Test org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase FAILED
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteOrganizationTestCase   
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteOrganizationTestCase   
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.898 sec              
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveOrganizationTestCase     
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveOrganizationTestCase     
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.687 sec              
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveServiceBindingTestCase   
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveServiceBindingTestCase   
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.705 sec              
>     [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase
>     [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase
>     [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 2.193 sec                
>     [junit] Test org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase FAILED
>     [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrConfimAssociationTestCase
>     [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrConfimAssociationTestCase
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.265 sec                    
>     [junit] Running org.jboss.test.jaxr.scout.query.JaxrBusinessQueryTestCase                
>     [junit] Running org.jboss.test.jaxr.scout.query.JaxrBusinessQueryTestCase                
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.187 sec                    
>     [junit] Running org.jboss.test.jaxr.scout.query.infomodel.JaxrFindAssociationsTestCase   
>     [junit] Running org.jboss.test.jaxr.scout.query.infomodel.JaxrFindAssociationsTestCase   
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.505 sec    
> ==================================

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-109) Cobertura 1.9.2
In-Reply-To: <2038758232.1246905891403.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <627876090.1248887490287.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-109.
-----------------------------------

    Resolution: Done


> Cobertura 1.9.2
> ---------------
>
>                 Key: JBJCA-109
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-109
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-119) Hibernate Validator
	4.0.0.Beta2
In-Reply-To: <1098713284.1247792429189.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <721520686.1248887490437.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-119.
-----------------------------------

    Resolution: Done


> Hibernate Validator 4.0.0.Beta2
> -------------------------------
>
>                 Key: JBJCA-119
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-119
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>
> for 303 requirement 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-120) Validation API
	1.0.CR3
In-Reply-To: <105271748.1248261929139.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1359600549.1248887490543.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-120.
-----------------------------------

    Resolution: Done


> Validation API 1.0.CR3
> ----------------------
>
>                 Key: JBJCA-120
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-120
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-121) SLF4J 1.5.6
In-Reply-To: <490362193.1248717809672.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <474286597.1248887490659.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-121.
-----------------------------------

    Resolution: Done


> SLF4J 1.5.6
> -----------
>
>                 Key: JBJCA-121
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-121
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-125) JBoss Classloading
	2.0.6.GA
In-Reply-To: <827060506.1248720089293.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <748193138.1248887490738.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-125.
-----------------------------------

    Resolution: Done


> JBoss Classloading 2.0.6.GA
> ---------------------------
>
>                 Key: JBJCA-125
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-125
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-99) Track component
	updates
In-Reply-To: <1859063348.1246366712646.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <46879599.1248887490087.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-99.
----------------------------------

    Resolution: Done


> Track component updates
> -----------------------
>
>                 Key: JBJCA-99
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-99
>             Project: JBoss JCA
>          Issue Type: Task
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>
> Track component updates for 1.0.0.Alpha2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-103) Javassist 3.11 GA
In-Reply-To: <1839914087.1246561131576.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1141112271.1248887490181.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-103.
-----------------------------------

    Resolution: Done


> Javassist 3.11 GA
> -----------------
>
>                 Key: JBJCA-103
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-103
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-126) JBoss Deployer
	2.0.8.GA
In-Reply-To: <290360875.1248720089360.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1387564072.1248887490829.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-126.
-----------------------------------

    Resolution: Done


> JBoss Deployer 2.0.8.GA
> -----------------------
>
>                 Key: JBJCA-126
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-126
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-127) JBoss MC Dependency
	2.0.8.GA
In-Reply-To: <1297570986.1248720089465.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1451725980.1248887490904.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-127.
-----------------------------------

    Resolution: Done


> JBoss MC Dependency 2.0.8.GA
> ----------------------------
>
>                 Key: JBJCA-127
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-127
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:11:30 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-128) JBoss MC Kernel
	2.0.8.GA
In-Reply-To: <1869359378.1248720209164.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1315733851.1248887490984.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-128.
-----------------------------------

    Resolution: Done


> JBoss MC Kernel 2.0.8.GA
> ------------------------
>
>                 Key: JBJCA-128
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-128
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:11:31 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 13:11:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-129) JBoss VFS 2.1.2.GA
In-Reply-To: <1486842312.1248720209260.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1720983048.1248887491093.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBJCA-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-129.
-----------------------------------

    Resolution: Done


> JBoss VFS 2.1.2.GA
> ------------------
>
>                 Key: JBJCA-129
>                 URL: https://jira.jboss.org/jira/browse/JBJCA-129
>             Project: JBoss JCA
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Alpha2
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:22:29 2009
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Wed, 29 Jul 2009 13:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-91) More modular
	packaging
Message-ID: <261113433.1248888149149.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

More modular packaging
----------------------

                 Key: JASSIST-91
                 URL: https://jira.jboss.org/jira/browse/JASSIST-91
             Project: Javassist
          Issue Type: Feature Request
            Reporter: Pete Muir
            Assignee: Shigeru Chiba
            Priority: Optional


It would great if you could just take the bits of Javassist you need - for example, we only ever use the proxy generation facility, and don't need any of the bytecode generation.

Motivation is simple - smaller dependencies (in jar file size).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:36:41 2009
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Wed, 29 Jul 2009 13:36:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6771) Typo in log message
 of WebServiceDeployerEJB.internalDeploy()
In-Reply-To: <15110409.1239539482895.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2125874086.1248889001479.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated JBAS-6771:
----------------------------------

    Assignee: Richard Opalka  (was: Alessio Soldano)


Richard, fix this comment typo if it's still there while merging your work on deployers to the trunk.

> Typo in log message of WebServiceDeployerEJB.internalDeploy()
> -------------------------------------------------------------
>
>                 Key: JBAS-6771
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6771
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-5.0.1.GA
>            Reporter: Hiranya Samarasekera
>            Assignee: Richard Opalka
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The word "Ignore" is mistyped as "Ingore" in the log message in method internalDeploy()
> log.warn("Ingore ejb deployment with null classname: " + ejb);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:36:41 2009
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Wed, 29 Jul 2009 13:36:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6771) Typo in log message
 of WebServiceDeployerEJB.internalDeploy()
In-Reply-To: <15110409.1239539482895.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2007219964.1248889001847.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated JBAS-6771:
----------------------------------

    Fix Version/s: JBossAS-5.2.0.Beta1


> Typo in log message of WebServiceDeployerEJB.internalDeploy()
> -------------------------------------------------------------
>
>                 Key: JBAS-6771
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6771
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-5.0.1.GA
>            Reporter: Hiranya Samarasekera
>            Assignee: Richard Opalka
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The word "Ignore" is mistyped as "Ingore" in the log message in method internalDeploy()
> log.warn("Ingore ejb deployment with null classname: " + ejb);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:40:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 29 Jul 2009 13:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7130) Stack trace when
 starting up "all" configuration
In-Reply-To: <1446554410.1248826962724.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <25241547.1248889229328.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478115#action_12478115 ] 

Stan Silvert commented on JBAS-7130:
------------------------------------

This is a bug in Mojarra:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1224

For now, you can work around the problem by placing an empty web.xml file in server/all/deploy/httpha-invoker.sar/invoker.war/WEB-INF

Once we get the JSF Deployer finished, this won't matter because Mojarra won't get called unless a FacesServlet exists in web.xml metadata.

> Stack trace when starting up "all" configuration
> ------------------------------------------------
>
>                 Key: JBAS-7130
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7130
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF, Web (Tomcat) service
>            Reporter: David Lloyd
>            Assignee: Stan Silvert
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> I get the following stack trace when starting up in the "all" configuration:
> 19:19:07,154 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
> 19:19:07,187 WARNING [config] Unable to process deployment descriptor for context '/invoker': java.lang.IllegalArgumentException: InputStream cannot be null
> 	at javax.xml.parsers.SAXParser.parse(SAXParser.java:194)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.scanForFacesServlet(ConfigureListener.java:752)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.<init>(ConfigureListener.java:712)
> 	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:165)
> 	at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:60)
> 	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
> 	at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:462)
> 	at org.jboss.web.deployers.WebModule.startModule(WebModule.java:116)
> 	at org.jboss.web.deployers.WebModule.start(WebModule.java:95)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:207)
> 	at $Proxy38.start(Unknown Source)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:653)
> 	at org.jboss.system.ServiceController.register(ServiceController.java:356)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerRegistrationLifecycleCallback.install(ServiceControllerRegistrationLifecycleCallback.java:104)
> 	at sun.reflect.GeneratedMethodAccessor239.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:42:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 29 Jul 2009 13:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7130) Stack trace when
 starting up "all" configuration
In-Reply-To: <1446554410.1248826962724.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <891337156.1248889349301.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert updated JBAS-7130:
-------------------------------

    Workaround Description: Place an empty web.xml file in server/all/deploy/httpha-invoker.sar/invoker.war/WEB-INF


> Stack trace when starting up "all" configuration
> ------------------------------------------------
>
>                 Key: JBAS-7130
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7130
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF, Web (Tomcat) service
>            Reporter: David Lloyd
>            Assignee: Stan Silvert
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> I get the following stack trace when starting up in the "all" configuration:
> 19:19:07,154 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
> 19:19:07,187 WARNING [config] Unable to process deployment descriptor for context '/invoker': java.lang.IllegalArgumentException: InputStream cannot be null
> 	at javax.xml.parsers.SAXParser.parse(SAXParser.java:194)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.scanForFacesServlet(ConfigureListener.java:752)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.<init>(ConfigureListener.java:712)
> 	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:165)
> 	at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:60)
> 	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
> 	at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:462)
> 	at org.jboss.web.deployers.WebModule.startModule(WebModule.java:116)
> 	at org.jboss.web.deployers.WebModule.start(WebModule.java:95)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:207)
> 	at $Proxy38.start(Unknown Source)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:653)
> 	at org.jboss.system.ServiceController.register(ServiceController.java:356)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerRegistrationLifecycleCallback.install(ServiceControllerRegistrationLifecycleCallback.java:104)
> 	at sun.reflect.GeneratedMethodAccessor239.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 13:55:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 13:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7130) Stack trace when
 starting up "all" configuration
In-Reply-To: <1446554410.1248826962724.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1340972933.1248890129331.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478117#action_12478117 ] 

David Lloyd commented on JBAS-7130:
-----------------------------------

OK, cool.  Just wanted to make sure that this was reported.

> Stack trace when starting up "all" configuration
> ------------------------------------------------
>
>                 Key: JBAS-7130
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7130
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF, Web (Tomcat) service
>            Reporter: David Lloyd
>            Assignee: Stan Silvert
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> I get the following stack trace when starting up in the "all" configuration:
> 19:19:07,154 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
> 19:19:07,187 WARNING [config] Unable to process deployment descriptor for context '/invoker': java.lang.IllegalArgumentException: InputStream cannot be null
> 	at javax.xml.parsers.SAXParser.parse(SAXParser.java:194)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.scanForFacesServlet(ConfigureListener.java:752)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.<init>(ConfigureListener.java:712)
> 	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:165)
> 	at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:60)
> 	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
> 	at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:462)
> 	at org.jboss.web.deployers.WebModule.startModule(WebModule.java:116)
> 	at org.jboss.web.deployers.WebModule.start(WebModule.java:95)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:207)
> 	at $Proxy38.start(Unknown Source)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:653)
> 	at org.jboss.system.ServiceController.register(ServiceController.java:356)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerRegistrationLifecycleCallback.install(ServiceControllerRegistrationLifecycleCallback.java:104)
> 	at sun.reflect.GeneratedMethodAccessor239.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 14:02:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 29 Jul 2009 14:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-132) Track component
	updates
Message-ID: <16504899.1248890549157.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Track component updates
-----------------------

                 Key: JBJCA-132
                 URL: https://jira.jboss.org/jira/browse/JBJCA-132
             Project: JBoss JCA
          Issue Type: Task
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha3




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 14:26:29 2009
From: jira-events at lists.jboss.org (Juan Manuel Medina Apodaca (JIRA))
Date: Wed, 29 Jul 2009 14:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6442) Response truncated
 in the presence of special character
In-Reply-To: <31820059.1233348224581.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1992406868.1248891989328.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juan Manuel Medina Apodaca updated JBAS-6442:
---------------------------------------------

    Attachment: SpecialChar.war


Hi.

You were right. The problem appears also if you print the special character directly from a servlet. The attached war reproduces the problem this way. It has only one servlet which prints messages before and after the special character.

If you print a few messages, nothing is shown. It seems like one has to fill the buffer before printing the special character in order to get some result in the Web page.

> Response truncated in the presence of special character
> -------------------------------------------------------
>
>                 Key: JBAS-6442
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6442
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows XP, JDK 1.6.0_11
>            Reporter: Juan Manuel Medina Apodaca
>            Assignee: Remy Maucherat
>         Attachments: SpecialChar.war, SpecialCharacter.txt
>
>
> When a servlet puts a session attribute containing a collection of strings, one of the strings contains a special character (for example: ...) and this string is displayed in a JSP, the resulting page is truncated before the special character.
> For example, in a servlet:
> ArrayList optionList = new ArrayList();
> ...
> optionList.add("Any string 1");
> optionList.add("Any string 2");
> optionList.add("Any string 3");
> optionList.add("Any string 4");
> optionList.add("A string with ... character");
> optionList.add("Any string 6");
> optionList.add("Any string 7");
> optionList.add("Any string 8");
> ...
> request.getSession(false).setAttribute("myList", optionList);
> In the JSP:
> 			               <c:forEach var="currentOption" items="${myList}">
> 			                  ${currentOption}
> 			                </c:forEach>
> The resulting page gets truncated before the 5th line.
> In JBoss 4.0.0 the page shows complete, with a ? sign in the place of the special character.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 14:34:29 2009
From: jira-events at lists.jboss.org (Juan Manuel Medina Apodaca (JIRA))
Date: Wed, 29 Jul 2009 14:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6442) Response truncated
 in the presence of special character
In-Reply-To: <31820059.1233348224581.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <257127958.1248892469234.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juan Manuel Medina Apodaca updated JBAS-6442:
---------------------------------------------

    Attachment: screenshot-1.jpg


This is the result of the execution of the test case. As you can see, it can be viewed using the path:     /SpecialChar/TestServlet

> Response truncated in the presence of special character
> -------------------------------------------------------
>
>                 Key: JBAS-6442
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6442
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows XP, JDK 1.6.0_11
>            Reporter: Juan Manuel Medina Apodaca
>            Assignee: Remy Maucherat
>         Attachments: screenshot-1.jpg, SpecialChar.war, SpecialCharacter.txt
>
>
> When a servlet puts a session attribute containing a collection of strings, one of the strings contains a special character (for example: ...) and this string is displayed in a JSP, the resulting page is truncated before the special character.
> For example, in a servlet:
> ArrayList optionList = new ArrayList();
> ...
> optionList.add("Any string 1");
> optionList.add("Any string 2");
> optionList.add("Any string 3");
> optionList.add("Any string 4");
> optionList.add("A string with ... character");
> optionList.add("Any string 6");
> optionList.add("Any string 7");
> optionList.add("Any string 8");
> ...
> request.getSession(false).setAttribute("myList", optionList);
> In the JSP:
> 			               <c:forEach var="currentOption" items="${myList}">
> 			                  ${currentOption}
> 			                </c:forEach>
> The resulting page gets truncated before the 5th line.
> In JBoss 4.0.0 the page shows complete, with a ? sign in the place of the special character.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 15:04:41 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 15:04:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-145) IDFedLSInputResolver
 should be made default for schema resolution
Message-ID: <1323610313.1248894281013.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

IDFedLSInputResolver should be made default for schema resolution
-----------------------------------------------------------------

                 Key: JBID-145
                 URL: https://jira.jboss.org/jira/browse/JBID-145
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 15:06:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 15:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-145) IDFedLSInputResolver
 should be made default for schema resolution
In-Reply-To: <1323610313.1248894281013.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <72018498.1248894389244.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-145.
------------------------------

    Resolution: Done


Disable by setting the system property "org.jboss.identity.federation.jaxb.ls" to a non-null value.

> IDFedLSInputResolver should be made default for schema resolution
> -----------------------------------------------------------------
>
>                 Key: JBID-145
>                 URL: https://jira.jboss.org/jira/browse/JBID-145
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 15:30:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 15:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-146) JAXBUtil: Marshaller
 setProperty formatted output should be false
Message-ID: <697355791.1248895829220.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JAXBUtil: Marshaller setProperty formatted output should be false
-----------------------------------------------------------------

                 Key: JBID-146
                 URL: https://jira.jboss.org/jira/browse/JBID-146
             Project: JBoss Identity
          Issue Type: Bug
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana


It will add newlines etc that can invalidate signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 15:30:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 15:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-146) JAXBUtil: Marshaller
 setProperty formatted output should be false
In-Reply-To: <697355791.1248895829220.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1061429405.1248895829339.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-146:
-------------------------------

          Component/s: Identity-Federation
        Fix Version/s: IDFED-1.0.0.beta1
    Affects Version/s: IDFED-1.0.0.alpha4


> JAXBUtil: Marshaller setProperty formatted output should be false
> -----------------------------------------------------------------
>
>                 Key: JBID-146
>                 URL: https://jira.jboss.org/jira/browse/JBID-146
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> It will add newlines etc that can invalidate signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 15:33:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 15:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBID-146) JAXBUtil:
 Marshaller setProperty formatted output should be false
In-Reply-To: <697355791.1248895829220.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <856504146.1248896009223.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBID-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478129#action_12478129 ] 

Anil Saldhana commented on JBID-146:
------------------------------------

http://forums.sun.com/thread.jspa?threadID=5198619&start=15&tstart=0  has some details.

> JAXBUtil: Marshaller setProperty formatted output should be false
> -----------------------------------------------------------------
>
>                 Key: JBID-146
>                 URL: https://jira.jboss.org/jira/browse/JBID-146
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> It will add newlines etc that can invalidate signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 15:35:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 15:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-146) JAXBUtil: Marshaller
 setProperty formatted output should be false
In-Reply-To: <697355791.1248895829220.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2069703874.1248896129199.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-146.
------------------------------

    Resolution: Done


> JAXBUtil: Marshaller setProperty formatted output should be false
> -----------------------------------------------------------------
>
>                 Key: JBID-146
>                 URL: https://jira.jboss.org/jira/browse/JBID-146
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> It will add newlines etc that can invalidate signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 15:35:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 15:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-147) XML Signature
 CanonicalizationMethod should be EXCLUSIVE_WITH_COMMENTS
Message-ID: <2016474749.1248896129276.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

XML Signature CanonicalizationMethod should be EXCLUSIVE_WITH_COMMENTS
----------------------------------------------------------------------

                 Key: JBID-147
                 URL: https://jira.jboss.org/jira/browse/JBID-147
             Project: JBoss Identity
          Issue Type: Bug
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha4
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1


Some details are at http://forums.sun.com/thread.jspa?threadID=5198619&start=15&tstart=0


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 15:58:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Wed, 29 Jul 2009 15:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6918) "trackByTxn" always
 gets displayed as "false" in the output of the "listStatistics" operation
 for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1582834059.1248897509318.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene reassigned JBAS-6918:
-------------------------------------

    Assignee: Charles Crouch  (was: Jason T. Greene)


I just checked with Jesper. This is deprecated, so it should just be ignored in the stats output

> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Charles Crouch
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 16:06:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 29 Jul 2009 16:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6918) "trackByTxn"
 always gets displayed as "false" in the output of the "listStatistics"
 operation for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1482674605.1248897989350.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478140#action_12478140 ] 

Ian Springer commented on JBAS-6918:
------------------------------------

Just to clarify, it's deprecated for all types of datasources and connection factories, or just for XA datasources and connection factories?


> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Charles Crouch
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 16:08:29 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Wed, 29 Jul 2009 16:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6918) "trackByTxn"
 always gets displayed as "false" in the output of the "listStatistics"
 operation for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <535282217.1248898109316.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478142#action_12478142 ] 

Ondrej ?i?ka commented on JBAS-6918:
------------------------------------

And to clarify more, does the property "interleaving" have the same meaning as _negated_ track-conn... ?

> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Charles Crouch
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Wed Jul 29 16:30:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Wed, 29 Jul 2009 16:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6918) "trackByTxn" always
 gets displayed as "false" in the output of the "listStatistics" operation
 for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1376930371.1248899429323.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch reassigned JBAS-6918:
------------------------------------

    Assignee: Jason T. Greene  (was: Charles Crouch)


Back to Jason for more info

> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Jason T. Greene
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 16:56:51 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Wed, 29 Jul 2009 16:56:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6918) "trackByTxn" always
 gets displayed as "false" in the output of the "listStatistics" operation
 for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1471685896.1248901011105.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer reassigned JBAS-6918:
----------------------------------

    Assignee: Jesper Pedersen  (was: Jason T. Greene)


> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Jesper Pedersen
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 17:18:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Jul 2009 17:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1691) JBM2 cluster
 fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1395189469.1248902309302.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic reassigned JBMESSAGING-1691:
--------------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)


> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Clebert Suconic
>         Attachments: cluster-nodes-config-files.zip, Jbm2ClusterTest-NodeA.zip, Jbm2ClusterTest-NodeB.zip
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 17:44:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 17:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7133) Logging error at
	midnight
Message-ID: <1226095905.1248903869144.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Logging error at midnight
-------------------------

                 Key: JBAS-7133
                 URL: https://jira.jboss.org/jira/browse/JBAS-7133
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Logging
            Reporter: David Lloyd
            Assignee: David Lloyd
            Priority: Minor
             Fix For: JBossAS-6.0.0.Alpha1


At midnight, we get:

LogManager error of type WRITE_FAILURE: Error writing log message
java.io.IOException: Stream closed
	at sun.nio.cs.StreamEncoder.ensureOpen(StreamEncoder.java:26)
	at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:99)
	at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:116)
	at java.io.OutputStreamWriter.write(OutputStreamWriter.java:203)
	at java.io.Writer.write(Writer.java:140)
	at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:65)
	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:59)
	at org.jboss.logmanager.Logger.logRaw(Logger.java:849)
	at org.slf4j.impl.Slf4jLogger.log(Slf4jLogger.java:68)
	at org.apache.commons.logging.impl.SLF4JLocationAwareLog.debug(SLF4JLocationAwareLog.java:120)
	at com.arjuna.common.internal.util.logging.jakarta.JakartaRelevelingLogger.debug(JakartaRelevelingLogger.java:172)
	at com.arjuna.common.internal.util.logging.LogNoi18nImpl.debug(LogNoi18nImpl.java:419)
	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:727)
	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:412)

...because of an order-of-operations error in the base logmanager handler.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 18:02:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 18:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCL-110) BaseClassLoader
 create message is insanely verbose
Message-ID: <1986339421.1248904949163.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

BaseClassLoader create message is insanely verbose
--------------------------------------------------

                 Key: JBCL-110
                 URL: https://jira.jboss.org/jira/browse/JBCL-110
             Project: JBoss ClassLoader
          Issue Type: Bug
          Components: ClassLoader, ClassLoaderPolicy, VFS
            Reporter: David Lloyd


When the AS starts up, we get messages like this:

19:18:42,479 DEBUG [BaseClassLoader] Created BaseClassLoader at 430e468f{vfsfile:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/conf/jboss-service.xml} with policy VFSClassLoaderPolicy at 5e3a78ad{name=vfsfile:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/conf/jboss-service.xml domain=null roots=[MemoryContextHandler at 1355339311[path= context=vfsmemory://3j001-2h0izc-fxpb6lon-1-fxpb6ps5-7 real=vfsmemory://3j001-2h0izc-fxpb6lon-1-fxpb6ps5-7], DelegatingHandler at 828756248[path=jacorb.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/jacorb.jar], DelegatingHandler at 327325694[path=jbosscache-core.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/jbosscache-core.jar], DelegatingHandler at 1657319091[path=avalon-framework.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/avalon-framework.jar], DelegatingHandler at 1699060847[path=jcip-annotations.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/jcip-annotations.jar], DelegatingHandler at 1025601370[path=jbosscache-pojo.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/jbosscache-pojo.jar], DelegatingHandler at 1578474768[path=jgroups.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/jgroups.jar], DelegatingHandler at 1559934385[path=hibernate-jbosscache2.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/all/lib/hibernate-jbosscache2.jar], DelegatingHandler at 1336846119[path=jbosssx-server.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbosssx-server.jar], DelegatingHandler at 357453361[path=jboss.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss.jar], DelegatingHandler at 1398807119[path=jmx-adaptor-plugin.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jmx-adaptor-plugin.jar], DelegatingHandler at 1247765324[path=jboss-jsr88.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-jsr88.jar], DelegatingHandler at 1013987513[path=jbossas-remoting.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossas-remoting.jar], DelegatingHandler at 1805392046[path=jboss-jmx-remoting.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-jmx-remoting.jar], DelegatingHandler at 1427668659[path=jboss-messaging-int.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-messaging-int.jar], DelegatingHandler at 992363882[path=jbossha.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossha.jar], DelegatingHandler at 1301762172[path=autonumber-plugin.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/autonumber-plugin.jar], DelegatingHandler at 153429168[path=hsqldb-plugin.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/hsqldb-plugin.jar], DelegatingHandler at 1703650176[path=scheduler-plugin.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/scheduler-plugin.jar], DelegatingHandler at 849042581[path=hsqldb.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/hsqldb.jar], DelegatingHandler at 1977308199[path=mail-plugin.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/mail-plugin.jar], DelegatingHandler at 309463268[path=properties-plugin.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/properties-plugin.jar], DelegatingHandler at 2091235889[path=jboss-srp.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-srp.jar], DelegatingHandler at 1684219621[path=scheduler-plugin-example.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/scheduler-plugin-example.jar], DelegatingHandler at 697219040[path=jboss-monitoring.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-monitoring.jar], DelegatingHandler at 1489627248[path=jboss-iiop.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-iiop.jar], DelegatingHandler at 800800410[path=jboss-iiop-client.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-iiop-client.jar], DelegatingHandler at 772475121[path=jboss-as-profileservice.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-as-profileservice.jar], DelegatingHandler at 1450712532[path=jboss-common-jdbc-wrapper.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-common-jdbc-wrapper.jar], DelegatingHandler at 1743680933[path=jboss-jca.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-jca.jar], DelegatingHandler at 1483593969[path=jbosscx-client.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbosscx-client.jar], DelegatingHandler at 331211666[path=jboss-management.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-management.jar], DelegatingHandler at 396857438[path=jboss-jsr77.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-jsr77.jar], DelegatingHandler at 2046236531[path=jboss-as-hibernate-int.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-as-hibernate-int.jar], DelegatingHandler at 1294253459[path=jbossjts.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossjts.jar], DelegatingHandler at 656024950[path=jcl-over-slf4j.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jcl-over-slf4j.jar], DelegatingHandler at 630290952[path=dtdparser.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/dtdparser.jar], DelegatingHandler at 1910683260[path=jboss-ejb3-proxy-spi.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-proxy-spi.jar], DelegatingHandler at 1530577229[path=jboss-ha-server-api.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ha-server-api.jar], DelegatingHandler at 1852364037[path=jboss-ejb3-common.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-common.jar], DelegatingHandler at 611939300[path=jboss-ejb3-ext-api-impl.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-ext-api-impl.jar], DelegatingHandler at 564629617[path=jboss-messaging.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-messaging.jar], DelegatingHandler at 2147220473[path=jboss-security-spi.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-security-spi.jar], DelegatingHandler at 2019285523[path=hibernate-jmx.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/hibernate-jmx.jar], DelegatingHandler at 1447711520[path=quartz.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/quartz.jar], DelegatingHandler at 697796130[path=jbossws-native-saaj.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossws-native-saaj.jar], DelegatingHandler at 451360643[path=servlet-api.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/servlet-api.jar], DelegatingHandler at 1106085697[path=jboss-ejb3-mc-int.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-mc-int.jar], DelegatingHandler at 1363861047[path=jbossjts-integration.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossjts-integration.jar], DelegatingHandler at 172168851[path=jboss-ejb3-metadata.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-metadata.jar], DelegatingHandler at 981406248[path=jboss-logging-log4j.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-logging-log4j.jar], DelegatingHandler at 1820401176[path=jbossts-common.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossts-common.jar], DelegatingHandler at 283046223[path=jboss-ejb3-deployers.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-deployers.jar], DelegatingHandler at 481591856[path=jboss-jpa-deployers.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-jpa-deployers.jar], DelegatingHandler at 248458249[path=log4j.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/log4j.jar], DelegatingHandler at 1129581175[path=jboss-ejb3-proxy-clustered.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-proxy-clustered.jar], DelegatingHandler at 1115368745[path=jboss-ejb3-timerservice-spi.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-timerservice-spi.jar], DelegatingHandler at 617742552[path=jboss-security-aspects.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-security-aspects.jar], DelegatingHandler at 1463121866[path=jboss-remoting.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-remoting.jar], DelegatingHandler at 2001443712[path=commons-collections.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/commons-collections.jar], DelegatingHandler at 80620976[path=jbossws-native-jaxws-ext.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossws-native-jaxws-ext.jar], DelegatingHandler at 2082046022[path=joesnmp.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/joesnmp.jar], DelegatingHandler at 1848947536[path=xnio-api.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/xnio-api.jar], DelegatingHandler at 1172865462[path=jboss-ha-client.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ha-client.jar], DelegatingHandler at 597424021[path=jsp-api.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jsp-api.jar], DelegatingHandler at 1419471222[path=jnpserver.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jnpserver.jar], DelegatingHandler at 656993631[path=jboss-ha-server-cache-jbc.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ha-server-cache-jbc.jar], DelegatingHandler at 1878526990[path=jboss-logging-jdk.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-logging-jdk.jar], DelegatingHandler at 98542736[path=jboss-ha-server-cache-spi.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ha-server-cache-spi.jar], DelegatingHandler at 497872115[path=jboss-ejb3-security.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-security.jar], DelegatingHandler at 1140348093[path=jboss-ejb3-endpoint.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-endpoint.jar], DelegatingHandler at 1686333223[path=jbossws-native-jaxws.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossws-native-jaxws.jar], DelegatingHandler at 1860789502[path=jbossxacml.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossxacml.jar], DelegatingHandler at 484808853[path=jboss-ejb3-transactions.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-transactions.jar], DelegatingHandler at 629435653[path=jaxen.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jaxen.jar], DelegatingHandler at 420574849[path=jboss-threads.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-threads.jar], DelegatingHandler at 1232804866[path=jbosssx.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbosssx.jar], DelegatingHandler at 829156606[path=jboss-negotiation.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-negotiation.jar], DelegatingHandler at 613691659[path=slf4j-api.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/slf4j-api.jar], DelegatingHandler at 2099239919[path=hibernate-core.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/hibernate-core.jar], DelegatingHandler at 916482070[path=jboss-current-invocation-aspects.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-current-invocation-aspects.jar], DelegatingHandler at 1561434206[path=antlr.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/antlr.jar], DelegatingHandler at 774533902[path=jboss-ejb3-core.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-core.jar], DelegatingHandler at 1692906447[path=jbossws-framework.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossws-framework.jar], DelegatingHandler at 667815626[path=jbossjts-jacorb.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossjts-jacorb.jar], DelegatingHandler at 1227686960[path=jboss-ejb3-interceptors.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-interceptors.jar], DelegatingHandler at 711856344[path=hibernate-annotations.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/hibernate-annotations.jar], DelegatingHandler at 538176171[path=jboss-remoting-aspects.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-remoting-aspects.jar], DelegatingHandler at 2073268480[path=jboss-ejb3-ext-api.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-ext-api.jar], DelegatingHandler at 353687138[path=jboss-transaction-aspects.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-transaction-aspects.jar], DelegatingHandler at 184993470[path=slf4j-jboss-logmanager.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/slf4j-jboss-logmanager.jar], DelegatingHandler at 1776413081[path=jboss-javaee.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-javaee.jar], DelegatingHandler at 1856991773[path=bsf.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/bsf.jar], DelegatingHandler at 1080886960[path=jboss-integration.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-integration.jar], DelegatingHandler at 902966747[path=hibernate-validator.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/hibernate-validator.jar], DelegatingHandler at 2042667127[path=jboss-metadata.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-metadata.jar], DelegatingHandler at 1432822547[path=bsh.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/bsh.jar], DelegatingHandler at 1714413618[path=jboss-serialization.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-serialization.jar], DelegatingHandler at 1361585927[path=hibernate-entitymanager.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/hibernate-entitymanager.jar], DelegatingHandler at 588932657[path=hibernate-commons-annotations.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/hibernate-commons-annotations.jar], DelegatingHandler at 439037176[path=ejb3-persistence.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ejb3-persistence.jar], DelegatingHandler at 144005940[path=jboss-jaspi-api.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-jaspi-api.jar], DelegatingHandler at 93763411[path=jboss-logmanager-log4j.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-logmanager-log4j.jar], DelegatingHandler at 1776135426[path=bcel.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/bcel.jar], DelegatingHandler at 1485411482[path=jbossws-native-jaxrpc.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossws-native-jaxrpc.jar], DelegatingHandler at 813381599[path=mail.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/mail.jar], DelegatingHandler at 1771121238[path=jbossws-common.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossws-common.jar], DelegatingHandler at 963815999[path=jboss-ejb3-cache.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-cache.jar], DelegatingHandler at 386345872[path=jbossws-spi.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jbossws-spi.jar], DelegatingHandler at 1472005823[path=jboss-ejb3-proxy-impl.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/jboss-ejb3-proxy-impl.jar], DelegatingHandler at 990253721[path=el-api.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/el-api.jar], DelegatingHandler at 196024597[path=log4j-snmp-appender.jar context=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/ real=file:/home/david/src/java/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/common/lib/log4j-snmp-appender.jar]]  delegates=null exported=[org.hibernate.loader.collection, , org.omg.CosNaming.NamingContextPackage, org.jboss.deployers.spi.management.deploy, org.jboss.remoting.transporter, org.jboss.cache.pojo.annotation, org.jboss.ejb3.proxy.clustered.objectfactory.session.stateful, com.arjuna.ats.internal.jta.transaction.jts.subordinate, com.arjuna.ats.internal.jts.interposition.resources.osi, com.arjuna.ats.txoj.semaphore, org.jboss.wsf.common.injection.finders, org.jboss.varia.property, org.jboss.jms.server.messagecounter, com.arjuna.common.util.logging, com.arjuna.common.util.propertyservice, com.arjuna.ats.internal.jts.orbspecific.interposition.resources.osi, org.jacorb.transport, org.jboss.remoting.samples.transporter.proxy, org.jboss.remoting.invocation, META-INF.maven.org.jboss.jbossas.jboss-as-hibernate-int, javax.persistence, org.hibernate.engine.loading, org.jboss.cache.annotations, org.jboss.security.xacml.sunxacml.combine, org.jboss.jms.client.remoting, org.jboss.remoting.samples.transporter.serialization.server, com.arjuna.ats.internal.txoj.recovery, org.jboss.cache.commands.legacy.write, javax.xml.registry.infomodel, org.omg.PortableServer.CurrentPackage, org.jboss.resource.adapter.jdbc.remote, com.arjuna.orbportability.orb, org.jboss.logging.log4j, org.jboss.resource.spi.timer, org.jboss.ha.cachemanager, META-INF.maven.org.jboss.logmanager.jboss-logmanager-log4j, org.jboss.web.tomcat.service.session.distributedcache.spi, org.jboss.wsf.test, org.jboss.ejb3.cluster.metadata, org.jgroups.tests.stack, org.jboss.metadata.annotation.creator.client, org.hibernate.cache.jbc2.query, org.jboss.resource.statistic.formatter, org.omg.CosEventChannelAdmin, com.arjuna.ats.internal.jta.transaction.arjunacore, org.jboss.security.mapping.providers.principal, org.jboss.hibernate.deployers.metadata, com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators, org.jboss.wsf.common.management, org.jboss.resource.metadata, javax.enterprise.deploy.spi, org.apache.log4j.lf5, org.jboss.remoting.detection.jndi, org.jboss.security.integration, com.arjuna.common.internal.util.logging.simpleLog, org.jboss.jms.server.remoting, org.jboss.ejb3.metadata, org.hibernate.cache.access, META-INF.maven.org.jboss.cluster.jboss-ha-server-api, org.jboss.remoting.samples.transporter.basic, org.apache.bsf.util, org.hibernate.intercept.cglib, org.jboss.remoting.transport.sslrmi, org.jgroups.mux, org.hibernate.proxy, org.jboss.cache.commands.tx, org.apache.bcel.verifier.exc, org.jboss.remoting.stream, com.arjuna.orbportability.internal, org.apache.log4j.varia, org.hibernate.cache, org.jboss.security.auth.container.config, org.jboss.jmx.adaptor.rmi, javax.security.auth.message.module, org.hibernate.usertype, org.jboss.management.j2ee.statistics, org.jboss.remoting, org.jboss.serial.util, org.jacorb.security.sas, org.jboss.security.acl.config, org.omg.Messaging, org.jboss.resource.adapter.jdbc.vendor, com.arjuna.ArjunaOTS, org.jboss.resource.adapter.jdbc, META-INF.maven.org.jboss.ws.native.jbossws-native-saaj, org.hibernate.ejb.event, org.jboss.metadata.validation.chain.ejb.jboss, com.arjuna.ats.internal.jts.utils, com.arjuna.ats.jta.utils, org.jboss.monitor.alerts, javax.servlet, org.hibernate.annotations, com.arjuna.ats.internal.jts.orbspecific.interposition.resources.arjuna, org.omg.GIOP, org.jboss.jms.wireformat, antlr.debug.misc, com.arjuna.ats.internal.arjuna.objectstore.jdbc, org.hibernate.hql.ast.exec, org.jboss.security.xacml.jaxb, org.jboss.ejb3.deployers, org.jboss.profileservice.cluster.repository, org.jboss.metadata.process.processor, org.jboss.wsf.spi.util, org.hibernate.context, org.jboss.remoting.samples.detection.multicast, org.jboss.xnio.management, org.jboss.jmx.connector.invoker, javax.enterprise.deploy.model, org.jboss.web.tomcat.service.session.distributedcache.impl.jbc, xmdesc, org.jboss.ejb3.interceptors.container, org.jboss.remoting.transport.web, META-INF.maven.org.hibernate.hibernate-jbosscache2, javax.enterprise.deploy.shared, org.hibernate.id.enhanced, org.jboss.metadata.common.jboss, org.hibernate.cache.jbc2.builder, org.jboss.ejb3.enc, org.jboss.ejb3.proxy.factory, org.jboss.cache.notifications.annotation, org.jboss.remoting.samples.callback.statistics, org.jboss.proxy.ejb.handle, com.arjuna.ats.jta.xa, org.jboss.ejb3.proxy.clustered.factory.session.stateful, org.jboss.metadata.serviceref, javax.mail.event, org.jboss.ejb3.proxy.impl.objectfactory.session.stateless, org.apache.bsf.engines.xslt, org.jaxen.pattern, org.jboss.ha.client.loadbalance, org.apache.log4j.lf5.viewer, org.jboss.ejb.plugins.cmp.jdbc, org.jboss.ejb3.proxy.impl.objectstore, org.jboss.metadata.annotation.finder, org.jboss.jms.server.security, org.jboss.aspects.currentinvocation, org.jboss.wsf.framework.serviceref, org.jboss.web.tomcat.service.session.distributedcache.impl, org.jboss.ejb3.dependency, org.jboss.iiop.jacorb, com.arjuna.ats.jbossatx.jta, org.omg.CORBA.TypeCodePackage, org.omg.PortableInterceptor, org.apache.bcel.generic, org.slf4j.helpers, org.quartz.plugins.xml, com.arjuna.ats.txoj.lockstore, META-INF.maven.org.jboss.ejb3.jboss-ejb3-timerservice-spi, com.sun.mail.handlers, org.jboss.remoting.serialization.impl.java, org.jboss.profileservice.management.mbean, org.jboss.metadata.jpa.spec, META-INF.maven.org.jboss.ejb3.jboss-ejb3-mc-int, org.jboss.cache.pojo.memory, org.jboss.ejb3.endpoint, org.hibernate.intercept.javassist, com.arjuna.orbportability.internal.orbspecific.orb.implementations, org.jboss.injection.lang.reflect, META-INF.maven.org.jboss.logging.jboss-logging-log4j, com.arjuna.ats.jbossatx.jts, org.jboss.ejb3.proxy.impl.objectfactory, org.jacorb.naming, org.jboss.ejb3.protocol.jarjar, org.jboss.remoting.transport.servlet, org.omg.CORBA_2_3, com.arjuna.ats.internal.jta.xa, org.jboss.ha.client.loadbalance.aop, org.omg.CORBA_2_5, org.hibernate.stat, javax.xml.ws, org.jboss.invocation.iiop, org.jboss.ejb3.proxy.impl.invocation, com.arjuna.ats.tsmx.mbeans, org.jboss.deployers.spi.management, org.jboss.varia.autonumber, org.quartz.simpl, org.jacorb.notification.servant, org.jboss.cache.factories.annotations, org.omg.PortableServer, org.jboss.security.plugins.acl, org.jboss.deployment.services, org.jboss.profileservice.management, org.jacorb.imr.RegistrationPackage, javax.xml.rpc.handler.soap, org.quartz.jobs, com.arjuna.orbportability.utils, org.omg.IOP.CodecFactoryPackage, org.jboss.ws.tools.io, org.hibernate.impl, com.arjuna.ats.internal.arjuna.gandiva.nameservice, org.jboss.wsf.common.reflection, org.hibernate.event.def, org.jboss.remoting.samples.multiplex, org.jgroups.annotations, org.hibernate.persister, org.hibernate.ejb.transaction, org.hibernate.validator.resources, org.omg.CosEventComm, org.jboss.remoting.samples.transporter.complex.server, org.jboss.remoting.marshal.serializable, org.jboss.ejb3.proxy.clustered.handler.session.stateful, org.jboss.security.mapping.providers, org.jboss.wsf.framework.management.recording, org.jboss.messaging.core.impl.jchannelfactory, org.jnp.interfaces, org.jboss.verifier, javax.xml.rpc, org.jboss.ejb3.interceptors.currentinvocation, org.opennms.protocols.snmp.asn1, org.hibernate.tool.instrument.cglib, org.jboss.profileservice.spi.metadata, org.jboss.client, org.hibernate.annotations.common.reflection.java, bsh.util.lib, com.arjuna.ats.internal.jts.orbspecific.interposition.coordinator, org.jboss.remoting.samples.transporter.multiple.client, org.jboss.security.xacml.interfaces, org.jboss.ha.hasessionstate.server, org.jboss.iiop.test, org.quartz.core, org.jboss.ejb.plugins.cmp.jdbc2.schema, org.jboss.ejb3.interceptors.proxy, META-INF.maven.org.jboss.jpa.jboss-jpa-deployers, com.arjuna.ats.internal.arjuna.template, com.arjuna.ats.txoj.logging, org.jboss.metadata.ejb.spec, org.hibernate.type, com.arjuna.ats.arjuna.gandiva.inventory, org.omg.IOP.CodecPackage, javax.xml.ws.http, org.jboss.verifier.strategy, com.arjuna.ats.jbossatx.logging, org.omg.PortableServer.portable, org.jgroups.auth, org.jgroups.conf, org.jboss.remoting.samples.transporter.custom.server, org.apache.bsf.util.event.adapters, org.jacorb.orb.policies, org.jboss.cache.config.parsing.element, org.jboss.cache.loader.jdbm, org.apache.commons.collections.set, org.apache.log4j.lf5.viewer.images, org.hibernate.loader, org.jboss.jms.delegate, org.hibernate.engine, org.quartz.spi, com.arjuna.ats.jts.common, META-INF.maven.org.jboss.ws.jbossws-common, org.jboss.security.propertyeditor, org.jboss.ha.framework.server.util, com.arjuna.orbportability.exceptions, org.jboss.mail, org.jboss.remoting.detection.util, org.jboss.ws.core.utils, org.jboss.ejb, com.arjuna.ats.jts.tx, org.jboss.wsf.spi.metadata.j2ee.serviceref, com.arjuna.ats.jdbc, org.jboss.ha.jndi.spi, com.arjuna.orbportability.internal.common, com.arjuna.orbportability.logging, org.jboss.serial.objectmetamodel, org.hsqldb.jdbc, META-INF.maven.org.hibernate.hibernate-core, com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca, org.jboss.cache.cluster, javax.mail.util, org.apache.log4j.nt, org.omg.PortableServer.ServantLocatorPackage, org.jboss.security.srp, com.arjuna.ats.internal.txoj.semaphore, com.arjuna.common.internal.util.propertyservice.plugins.io, org.jboss.security.xacml.locators, com.arjuna.ats.internal.jbossatx.jta.jca, org.hibernate.tuple, org.jboss.remoting.transport.rmi, org.hibernate.annotations.common.reflection, bsh.reflect, org.hibernate.classic, org.jboss.web, org.hibernate.ejb.connection, org.jboss.security.xacml.util, org.jgroups.tests, org.jboss.security.ssl, org.jboss.ejb3.mdb, javax.transaction.xa, org.apache.bsf.engines.netrexx, org.hsqldb, javax.security.auth.message.config, org.hibernate.jdbc.util, com.arjuna.ats.jta.common, org.omg.CosTypedNotifyComm, META-INF.maven.org.jboss.ejb3.jboss-ejb3-endpoint, com.wutka.dtd, org.jboss.jms.server.connectormanager, com.arjuna.ats.jts.utils, org.jboss.metadata.process.processor.ejb.jboss, org.jboss.cache.pojo.notification.event, org.jboss.cache.loader.tcp, org.omg.stub.javax.ejb, org.jboss.jpa.tx, org.hibernate.loader.entity, org.jboss.remoting.samples.oneway, org.jacorb.orb.dii, org.jboss.messaging.core.impl.clusterconnection, com.arjuna.ats.internal.jta.utils.jts, org.jboss.wsf.spi.deployment, org.jboss.ejb3.interceptors.direct, antlr.collections.impl, org.hibernate, org.apache.log4j.or, org.jboss.cache.factories, javax.xml.rpc.soap, org.hibernate.bytecode.util, org.hsqldb.sample, org.jboss.ha.jndi, com.arjuna.ats.internal.tsmx.agent.exceptions, org.hsqldb.lib, org.jboss.ejb3.metamodel, com.arjuna.ats.txoj.exceptions, org.omg.CosTypedNotifyChannelAdmin, com.arjuna.ats.jts.exceptions, org.omg.CosNotifyFilter, javax.management.remote.rmi, org.apache.log4j.or.jms, javax.interceptor, META-INF.maven.org.jboss.ws.native.jbossws-native-jaxws-ext, org.jboss.wsf.spi.tools.ant, security, org.jboss.resource.timer, com.arjuna.ats.tsmx.agent.exceptions, org.apache.avalon.framework.activity, com.arjuna.ats.jta.transaction, org.jacorb.orb.giop, org.jboss.ejb3.metadata.plugins.loader, org.jboss.deployment.vfs, com.arjuna.ats.internal.jta.recovery.arjunacore, org.jaxen, com.arjuna.ats.internal.jts.lifecycle, com.arjuna.ats.jta.resources, org.jboss.wsf.common.logging, org.jboss.ejb3.aop, META-INF.maven.org.jboss.ejb3.jboss-ejb3-security, org.omg.DynamicAny, com.arjuna.ats.arjuna.utils, org.jboss.jms.client.delegate, bsh.commands, org.jacorb.orb.iiop, com.arjuna.ats.tsmx.agent, org.jboss.security.xacml.sunxacml.support, org.jboss.serial.finalcontainers, com.arjuna.ats.internal.txoj.lockstore, org.jboss.resource.security, com.arjuna.ats.jts.recovery, org.jboss.messaging.core.impl.tx, org.jgroups.debug, org.jboss.cache.eviction, org.jboss.resource.connectionmanager, javax.xml.ws.addressing.soap, org.jboss.deployment.dependency, com.arjuna.ats.internal.jdbc.drivers, org.quartz.impl.calendar, org.jboss.security.identity.fed, com.arjuna.ats.internal.jts.orbspecific.recovery.recoverycoordinators, org.jboss.ejb3.kernel, META-INF.maven.org.jboss.ejb3.jboss-ejb3-proxy-clustered, org.jboss.wsf.framework, com.arjuna.ats.arjuna.coordinator, org.jboss.invocation, javax.servlet.http, org.jboss.metadata.validation, com.arjuna.common.internal.util.licence.utils, org.jacorb.util, org.hibernate.bytecode, javax.jws, org.jboss.jms.exception, org.jboss.security.mapping, org.jboss.ejb3.interceptors.lang, org.apache.log4j.spi, org.jboss.ejb3.common.resolvers.spi, org.jboss.logmanager.log4j.handlers, org.jboss.ejb3.core.resolvers, com.arjuna.ats.jts.thread, org.jboss.logmanager.log4j, com.arjuna.ats.arjuna.gandiva.nameservice, org.jboss.ejb3.naming, org.jboss.security.xacml.sunxacml.ctx, org.jboss.messaging.core.impl, org.jboss.remoting.samples.transporter.clustered.server, org.jboss.jpa.resolvers, META-INF.maven.org.jboss.slf4j.slf4j-jboss-logmanager, org.hsqldb.util.sqltool, org.jboss.hibernate.deployers, org.jboss.ejb.plugins.local, org.jacorb.events, org.jboss.cache.pojo, org.jboss.monitor, org.jboss.cache.pojo.notification, org.jboss.remoting.samples.transporter.proxy.client, org.hibernate.cache.entry, org.jboss.threads, org.quartz, org.hibernate.hql, org.jgroups.protocols.pbcast, org.jboss.security.auth.spi, org.hibernate.tuple.component, org.hibernate.transform, com.arjuna.common.util, com.arjuna.orbportability.internal.orbspecific.jacorb.orb.implementations, org.jboss.ejb3.cache.persistence, org.jboss.invocation.pooled.server, org.jboss.security.identitytrust.modules, org.jboss.metadata.common.spi, com.arjuna.ats.internal.jta.utils, org.jboss.cache.pojo.util, com.arjuna.ats.internal.jts.orbspecific.recovery, org.jboss.cache.notifications.event, org.jboss.security.authorization.modules, org.jboss.verifier.event, org.jboss.iiop.rmi.marshal, org.jboss.ejb3.proxy.clustered.registry, org.apache.log4j.jdbc, org.jgroups.tests.perf.transports, com.arjuna.ats.internal.jta.recovery.jts, org.jboss.ejb3.common.resolvers.plugins, org.apache.bcel.util, org.jboss.annotation.javaee, com.arjuna.ats.internal.jta.resources.errorhandlers, org.jboss.ejb3.proxy.clustered.familyname, org.jboss.ejb3.metadata.annotation, org.hibernate.sql, org.omg.TimeBase, org.jboss.messaging.util, org.jboss.ejb.plugins.cmp.jdbc.metadata, org.jacorb.notification.conf, com.arjuna.common.util.propertyservice.propertycontainer, org.hsqldb.persist, org.jboss.invocation.http.server, org.jboss.wsf.spi.metadata.injection, org.jboss.remoting.transport.sslsocket, org.jboss.ejb3.interceptors.aop, org.hibernate.lob, com.arjuna.ats.arjuna.state, org.jboss.ejb3.security.helpers, org.jboss.ejb3.proxy.impl.objectfactory.session, org.jboss.wsf.spi.management, org.jboss.remoting.detection.multicast, org.jboss.security.authorization.modules.web, antlr.build, org.hibernate.persister.entity, org.jboss.classloading.spi, org.jboss.metadata.rar.jboss, org.jboss.jpa.injection, org.apache.bsf.engines.jacl, org.jboss.mx.remoting.event, org.jboss.wsf.common.concurrent, META-INF.maven.org.jboss.ejb3.jboss-ejb3-ext-api, org.jboss.jca.spi, org.jboss.remoting.samples.bisocket, com.arjuna.orbportability.internal.orbspecific.oa.implementations, org.omg.CORBA.InterfaceDefPackage, META-INF.maven.org.jboss.jbossas.jboss-as-management, org.apache.log4j.lf5.viewer.configure, org.jboss.logging.jdk.handlers, org.jboss.ejb3.security.embedded.plugins, org.jboss.ejb3.common.registrar.spi, org.jboss.naming.java, org.jboss.crypto.digest, org.apache.avalon.framework.thread, org.jboss.security.xacml.sunxacml, org.jboss.remoting.samples.transporter.complex, org.jacorb.ir, META-INF.maven.org.jboss.ejb3.jboss-ejb3-ext-api-impl, org.jgroups.demos.applets, com.arjuna.ats.arjuna.thread, org.apache.commons.collections.map, javax.xml.rpc.holders, org.jboss.jms.server.plugin.contract, org.jboss.ejb3.interceptors.registry, org.omg.CosPropertyService, org.jboss.tm.usertx.client, org.jboss.security.negotiation.ntlm.encoding, org.hibernate.cfg.search, com.arjuna.ats.txoj, org.jboss.remoting.transport.bisocket, org.jboss.resource.binding.remote, org.jboss.ejb3.injection, com.arjuna.ats.txoj.common, org.jboss.wsf.spi.serviceref, javax.security.jacc, org.jacorb.orb.listener, org.jboss.ejb3.proxy.impl.factory.session, org.jboss.wsf.common.utils, META-INF.maven.org.jboss.ws.native.jbossws-native-jaxrpc, org.jboss.jms.server.bridge, org.jgroups, com.arjuna.ats.internal.arjuna, javax.enterprise.deploy.spi.exceptions, org.omg.SecurityAdmin, org.quartz.xml, org.jboss.management.j2ee, org.jboss.deployment.spi.configurations, bsh.servlet, org.jboss.aspects.tx, org.apache.commons.collections.iterators, org.jboss.serial.io, org.jboss.cache.util, org.jacorb.dds, META-INF.maven.org.jboss.jbossas.jboss-as-profileservice, com.arjuna.orbportability.internal.orbspecific.jacorb.oa.implementations, com.arjuna.orbportability.orb.core, org.hibernate.cfg.annotations.reflection, org.hibernate.id, com.arjuna.ats.internal.jts.interposition.resources.strict, org.jboss.ejb3.common.thread, org.jboss.config, com.arjuna.common, org.jboss.jpa.util, org.jboss.deployment, org.jacorb.poa.gui.poa, org.apache.avalon.framework.logger, javax.ejb.spi, org.jboss.cache.util.concurrent, org.jboss.ejb3.common.metadata, bsh.collection, org.jboss.metamodel.descriptor, com.arjuna.ats.internal.jta.transaction.jts.jca, org.jboss.ejb3.proxy.impl.factory.session.service, org.jboss.profileservice.management.upload, org.jboss.invocation.local, META-INF.maven.org.slf4j.slf4j-api, org.jaxen.function, META-INF.maven.org.jboss.cluster.jboss-ha-client, org.jboss.logging.appender, org.jboss.security.microcontainer.beans.metadata, org.jboss.remoting.samples.multiplex.invoker, org.jboss.cache.buddyreplication, com.arjuna.ats.arjuna.objectstore.jdbc, org.jaxen.javabean, org.jboss.ejb3.tx.container, org.jboss.lang.ref, org.hsqldb.resources, org.jboss.security.xacml.sunxacml.finder.impl, org.jboss.ejb3.common.spi, org.jboss.metadata.process.chain.ejb.jboss, com.arjuna.ats.internal.jta.resources.jts.orbspecific, org.jboss.security.xacml.sunxacml.support.finder, org.jboss.jms.server.container, org.jboss.profileservice.management.templates, org.apache.bsf.util.cf, org.quartz.utils, org.hibernate.validator.event, org.jboss.ha.framework.test, javax.security.auth.message.callback, org.jboss.ejb3.common.lang, org.hsqldb.lib.java, org.jacorb.security.ssl.sun_jsse, org.jboss.cache.lock, org.jboss.iiop.naming, org.jboss.cache.pojo.notification.annotation, com.arjuna.ats.internal.jts.interposition, org.jboss.cache.loader.s3, org.jboss.security.xacml.bridge, org.jboss.remoting.samples.chat, org.jacorb.orb.etf, org.jnp.server, com.arjuna.ats.internal.jbossatx.jts, org.hsqldb.scriptio, org.jboss.metadata.client.spec, org.w3c.dom, org.jboss.logging.filter, org.jaxen.function.ext, com.arjuna.ats.tsmx.common, javax.management.remote, org.omg.dds, com.arjuna.ats.internal.jbossatx.jta, org.jboss.ejb3.security.annotation, org.jacorb.notification.interfaces, org.jnp.interfaces.java, bsh, org.jboss.ejb3.entity.hibernate, org.apache.log4j.lf5.util, org.jboss.metadata.annotation.creator.ws, org.jaxen.saxpath.helpers, org.quartz.plugins.management, org.jboss.remoting.samples.transporter.proxy.server, javax.jms, org.omg.CORBA, antlr.actions.python, org.jboss.ejb3.util, org.hibernate.loader.custom, stylesheets, javax.jws.soap, org.jnp.client, org.jboss.profileservice.management.upload.remoting, org.hibernate.engine.query.sql, org.jboss.ejb3.common.string, org.jboss.metadata.validation.validator.ejb.jboss, org.jboss.ejb3.metadata.spi.signature, org.jboss.ejb3.javaee, javax.resource.spi, org.hibernate.persister.collection, org.hibernate.hql.ast.tree, org.jboss.remoting.samples.simple, org.jboss.remoting.serialization, org.omg.CosNotifyChannelAdminAck, org.apache.avalon.framework.service, org.jboss.profileservice.management.matchers, org.jaxen.expr.iter, org.jboss.ejb3.proxy.impl.remoting, org.jboss.remoting.transport.servlet.web, org.jacorb.notification.engine, org.jboss.ha.singleton.examples, org.jacorb.transport.iiop, com.arjuna.ats.internal.jts.orbspecific.interposition.resources.restricted, org.jboss.ejb3.proxy.clustered.objectstore, org.jboss.remoting.samples.chat.utility, org.jboss.ejb3.timerservice.spi, org.jboss.jms.client.plugin, org.jboss.remoting.transport.sslservlet, com.arjuna.ats.internal.jts.resources, org.jboss.ejb3.proxy, org.jboss.security.plugins.audit, org.hibernate.hql.antlr, com.arjuna.ats.internal.jts.recovery.contact, org.jboss.security.identitytrust, org.jboss.ejb3.interceptors.annotation, org.jboss.deployment.spi.status, org.jacorb.transaction, org.jboss.cache.transaction, org.hibernate.proxy.pojo.javassist, org.jboss.remoting.loading, com.arjuna.ats.jts.extensions, javax.resource.spi.work, org.hibernate.cache.jbc2, com.arjuna.ats.jts.orbspecific.jacorb.interceptors.context, org.jboss.logging.jdk, org.omg.SSLIOP, com.arjuna.common.util.exceptions, org.jboss.security.jndi, org.apache.commons.collections.bidimap, META-INF.maven.org.jboss.aspects.jboss-remoting-aspects, org.jboss.ejb.plugins.lock, org.apache.bcel.verifier.structurals, org.jboss.remoting.samples.transporter.multiple, org.jboss.aspects.remoting.interceptors.invoker, org.jacorb.orb.portableInterceptor, org.quartz.helpers, org.jboss.varia.scheduler.example, com.arjuna.ats.jdbc.common, org.jboss.mx.remoting.provider.iiop, org.jboss.crypto, org.apache.bsf, org.jboss.security.identity, org.quartz.utils.weblogic, javax.servlet.jsp.tagext, org.jacorb.util.tracing.TracingServicePackage, org.hibernate.jmx, com.arjuna.ats.jbossatx, org.jboss.resource.work, javax.enterprise.deploy.spi.status, org.jboss.security.identitytrust.config, com.arjuna.ats.internal.jts.orbspecific.interposition.resources, org.jboss.metadata.validation.validator, org.hibernate.hql.ast, org.jboss.cache.pojo.interceptors, antlr, org.jacorb.poa.except, com.arjuna.ats.internal.txoj, org.jboss.resource.statistic, org.jboss.naming, org.jacorb.util.tracing, org.jboss.jms.server.connectionfactory, org.jboss.remoting.detection, org.hibernate.proxy.map, org.jboss.metadata.validation.chain, org.apache.commons.collections.buffer, org.jboss.wsf.spi.binding, org.jboss.wsf.spi.invocation, org.jboss.remoting.security, org.hibernate.annotations.common.util, javax.xml.registry, org.jboss.jpa.remote, org.jboss.metadata.javaee.jboss, org.jaxen.jdom, org.jboss.messaging.core.contract, org.jacorb.poa, org.jboss.ejb3.common.registrar.plugin.mc, org.jacorb.notification, org.jboss.messaging.util.prioritylinkedlist, org.apache.bsf.engines.javascript, antlr.preprocessor, com.arjuna.orbportability, com.arjuna.orbportability.common, org.jboss.wsf.framework.http, org.jboss.security.integration.password, org.jboss.ejb.plugins.jms, org.jboss.security.jce, org.quartz.ee.jmx.jboss.doc-files, javax.xml.rpc.server, org.jboss.ejb3.proxy.clustered.factory.session.stateless, com.sun.mail.smtp, org.omg.PortableInterceptor.ORBInitInfoPackage, org.jboss.cache.commands.remote, org.jboss.metadata.web.jboss, META-INF.maven.org.jboss.jbossas.jboss-as-messaging, org.jboss.remoting.transport.multiplex, org.jboss.executor, org.quartz.jobs.ee.mail, org.omg.CosConcurrencyControl, org.jboss.wsf.common, org.apache.log4j.or.sax, org.hibernate.cache.jbc2.util, org.jboss.cache.jmx, com.arjuna.orbportability.internal.utils, org.jaxen.util, org.jboss.remoting.samples.http, org.jacorb.notification.lifecycle, org.jboss.aspects.security, org.jboss.security.acl, org.omg.CORBA_2_3.portable, com.arjuna.common.util.concurrency, org.hibernate.cache.jbc2.entity, org.hibernate.engine.transaction, org.jboss.cache.config, org.hibernate.bytecode.cglib, org.jboss.jms.server.destination, org.jboss.util.stream, javax.enterprise.deploy.shared.factories, org.omg.DynamicAny.DynAnyFactoryPackage, org.jboss.ejb3.common.proxy.spi, org.jgroups.demos, org.jboss.ejb3.annotation, org.jboss.corba, org.jboss.cache.pojo.eviction, org.hibernate.loader.criteria, org.jboss.metadata.merge, org.jboss.logging.layout, org.jboss.ejb3.proxy.clustered.objectfactory.session.stateless, org.jboss.ejb3.proxy.clustered.jndiregistrar, com.arjuna.ats.internal.tsmx.mbeans, org.hibernate.annotations.common, org.jboss.remoting.ident, org.jboss.invocation.unified.interfaces, org.jboss.security.plugins.authorization, org.jboss.ejb.deployers, META-INF.maven.org.jboss.ejb3.jboss-ejb3-proxy-spi, org.hsqldb.util, org.jboss.hibernate, META-INF.maven.org.jboss.ejb3.jboss-ejb3-proxy-impl, META-INF.maven.org.slf4j.jcl-over-slf4j, org.jgroups.demos.wb, org.jboss.ejb3.metadata.jpa.spec, org.apache.avalon.framework.parameters, org.apache.avalon.framework.context, org.jboss.ha.framework.server.spi, org.jboss.ejb3.interceptor, org.jboss.jms.server.endpoint.advised, javax.servlet.jsp, org.jboss.mx.remoting, org.jboss.security.factories, org.jboss.resource.connectionmanager.xa, org.jboss.verifier.factory, org.jboss.ha.hasessionstate.interfaces, org.jboss.aspects.remoting.interceptors.marshall, org.hibernate.engine.query, META-INF.maven.org.jboss.ejb3.jboss-ejb3-cache, org.apache.commons.logging, org.jboss.deployment.security, org.jboss.jpa.javaee, META-INF.maven.org.jboss.jbossas.jboss-as-jmx-remoting, org.jboss.iiop.rmi.marshal.strategy, org.jboss.cache.invalidation.triggers, org.jboss.ejb3.endpoint.reflect, com.arjuna.ats.internal.arjuna.objectstore, org.omg.PortableServer.POAManagerPackage, org.jboss.tm, javax.resource.cci, org.jboss.jms.server, org.jboss.security.auth, org.jboss.management.j2ee.deployers, org.jacorb.notification.filter.impl, org.jboss.security.srp.jaas, com.arjuna.common.internal.util.propertyservice, javax.xml.ws.spi, org.jboss.naming.interceptors, org.jboss.metadata.annotation.creator.ejb.jboss, org.jboss.security.xacml.sunxacml.cond, org.jboss.security, com.arjuna.orbportability.recovery, org.jacorb.notification.filter.etcl, org.jboss.security.auth.message.config, org.apache.commons.collections.functors, META-INF.maven.org.jboss.jbossas.jboss-as-cluster, META-INF.maven.org.jboss.cluster.jboss-ha-server-cache-jbc, org.jboss.ejb3.proxy.clustered.invocation, org.jboss.ejb3.proxy.impl.objectfactory.session.stateful, org.hibernate.mapping, org.apache.avalon.framework, org.jboss.metadata.process, org.jboss.jms.server.endpoint, META-INF.services, org.quartz.impl, org.jboss.security.negotiation.common, com.arjuna.ats.internal.jts.orbspecific.interposition.resources.strict, org.jboss.ejb3.proxy.impl.handler.session, org.jgroups.jmx.protocols, org.hibernate.validator.interpolator, META-INF.maven.org.jboss.ws.jbossws-framework, org.jboss.ejb3.security, org.jboss.security.auth.login, com.arjuna.ats.jts.logging, org.apache.bsf.util.type, org.apache.commons.collections.collection, org.jboss.jms.client.state, org.jboss.remoting.samples.transporter.multiple.server, com.arjuna.ats.internal.jta.resources.arjunacore, org.jboss.remoting.samples.config.factories, org.jboss.ejb3.common.proxy.plugins.async, org.hibernate.ejb.instrument, org.apache.log4j.xml, org.jboss.remoting.samples.transporter.serialization, org.hibernate.action, org.jboss.resource, org.jboss.wsf.spi.tools, org.jboss.deployment.spi.beans, org.jboss.remoting.samples.transporter.clustered.client, com.arjuna.ats.internal.jts.recovery.recoverycoordinators, org.jboss.ejb3, org.jboss.metadata.annotation.creator, org.jboss.ha.framework.server.deployers, org.apache.bsf.engines.jython, org.jboss.wsf.framework.invocation, org.quartz.jobs.ee.jmx, org.jboss.invocation.jrmp.server, org.jgroups.util, org.jboss.wsf.spi.annotation, org.jboss.ejb3.connectionmanager, org.hibernate.dialect, com.arjuna.ats.internal.jta.resources.jts, org.jboss.ejb3.jms, org.jboss.invocation.unified.marshall, org.jacorb.poa.util, org.jboss.messaging.core.jmx, META-INF.maven.org.jboss.jbossas.jboss-as-jbossas-remoting, org.jboss.ejb3.common.classloader, org.jboss.wsf.spi.deployment.integration, javax.mail, org.jboss.jpa.resolvers.strategy, org.hibernate.bytecode.javassist, org.apache.log4j.helpers, META-INF.maven.org.jboss.metadata.jboss-metadata, com.arjuna.ats.jta.recovery, org.jboss.security.xacml.core.ext, org.jboss.proxy.generic, org.jboss.metadata.lang, org.jacorb.orb.dynany, org.omg.CosTypedEventChannelAdmin, com.arjuna.ats.arjuna, org.slf4j.impl, com.arjuna.ats.internal.tsmx.agent.implementations.ri, org.hsqldb.index, org.jboss.persistence, org.hibernate.connection, org.jboss.remoting.serialization.impl.jboss, org.jboss.aspects.remoting, org.jboss.web.tomcat.service.sso.spi, org.jboss.jms.server.connectionmanager, org.hibernate.proxy.pojo, org.jaxen.expr, org.jboss.remoting.samples.detection.jndi.ssl, org.jboss.messaging.core.impl.message, org.jboss.security.authorization.resources, org.jboss.metadata.ejb.jboss, org.jboss.ejb.plugins.cmp.jdbc2, antlr.collections, org.jboss.security.cache, javax.enterprise.deploy.model.exceptions, org.jboss.web.tomcat.service.sso.jbc, org.hsqldb.rowio, META-INF, org.jboss.mx.remoting.tracker, org.jboss.mx.remoting.provider.rmi, org.omg.Security, org.jboss.security.xacml.core, com.arjuna.ats.txoj.tools, org.jboss.cache.remoting.jgroups, org.jboss.wsf.spi.metadata.webservices, org.jboss.security.authorization.util, META-INF.maven.org.jboss.cache.jbosscache-core, org.quartz.ee.jmx.jboss, org.hibernate.validator, org.apache.commons.collections.keyvalue, com.arjuna.ats.internal.arjuna.coordinator, org.jacorb.poa.gui, org.omg.CosTypedEventComm, org.jboss.security.xacml.sunxacml.attr.proxy, javax.mail.internet, org.jboss.ha.framework.interfaces, com.arjuna.ats.arjuna.objectstore, org.apache.log4j.lf5.config, org.jboss.metadata.annotation.creator.jboss, org.jboss.invocation.pooled.interfaces, javax.xml.ws.handler, org.jboss.metadata.ejb.jboss.proxy, org.jboss.ejb3.cache, org.jboss.cache.util.concurrent.locks, org.jboss.remoting.samples.transporter.basic.client, com.arjuna.ats.internal.jta.resources, org.quartz.ee.jta, org.hibernate.transaction, org.jboss.security.config, com.arjuna.ats.internal.jta.utils.arjunacore, org.omg.IOP, javax.security.auth.message, org.jboss.ejb3.proxy.clustered.handler.session.stateless, org.jboss.ejb3.cache.tree, org.jboss.remoting.samples.callback.acknowledgement, org.omg.Dynamic, org.jboss.remoting.samples.serialization, org.jboss.cache.notifications, org.omg.DynamicAny.DynAnyPackage, org.jboss.hibernate.jmx, com.sun.mail.iap, META-INF.maven.org.jboss.aspects.jboss-current-invocation-aspects, org.jboss.ejb3.statistics, org.jboss.jms, org.jboss.ejb.plugins.cmp.jdbc.keygen, org.hibernate.cache.jbc2.collection, org.jboss.ejb3.proxy.impl.objectfactory.session.service, org.jboss.cache.factories.context, org.hibernate.intercept, org.apache.commons.logging.impl, com.arjuna.ats.internal.jdbc.recovery, org.jboss.jmx.connector.invoker.serializablepolicy, org.quartz.plugins.history, javax.ejb, org.jboss.ha.singleton, org.apache.avalon.framework.configuration, com.sun.mail.imap, org.apache.commons.collections, org.hibernate.jdbc, org.jboss.ejb.plugins.keygenerator, org.omg.RTCORBA, org.jboss.security.audit, org.jboss.wsf.spi.http, org.jboss.managed.plugins.advice, com.arjuna.ats.internal.jts.orbspecific, org.hsqldb.store, org.slf4j.spi, org.jboss.wsf.spi, org.jboss.remoting.samples.transporter.complex.client, org.jgroups.jmx, org.jboss.jms.recovery, org.jboss.iiop, org.jboss.security.xacml.sunxacml.cond.cluster, org.jboss.ha.jmx.examples, org.jboss.monitor.client, com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate, org.hibernate.secure, org.jboss.metadata, org.jboss.ejb3.tx, org.jboss.security.callbacks, com.arjuna.ats.internal.arjuna.thread, org.jboss.ejb3.interceptors, javax.xml.ws.soap, org.quartz.impl.jdbcjobstore.oracle, org.omg.XA, org.jboss.ejb3.proxy.spi.container, org.jboss.wsf.spi.metadata.j2ee, org.hibernate.cfg, javax.xml.ws.wsaddressing, com.arjuna.ats.internal.jts, org.jboss.management.j2ee.cluster, org.jboss.security.client, com.arjuna.ats.jts.orbspecific.jacorb.interceptors.interposition, org.omg.BiDirPolicy, org.jboss.ejb3.interceptors.metadata, org.jboss.security.plugins.identitytrust, org.hibernate.tool.instrument.javassist, org.jboss.ejb3.remoting, org.jboss.metadata.ejb.jboss.jndipolicy.spi, com.arjuna.ats.internal.jta, org.jboss.security.plugins.javaee, org.omg.CosNotifyCommAck, org.hibernate.cache.jbc2.timestamp, org.omg.GSSUP, org.jaxen.saxpath.base, org.jboss.remoting.network.filter, META-INF.maven.org.jboss.ejb3.jboss-ejb3-interceptors, org.jacorb.notification.impl, org.jboss.remoting.marshal, org.jboss.ejb3.resolvers, org.apache.avalon.framework.container, org.jboss.ejb3.proxy.impl.factory, org.hibernate.cache.impl, org.jboss.serial.exception, org.jboss.proxy.compiler, org.jboss.jpa.deployment, org.hibernate.id.insert, org.jboss.invocation.unified.server, org.jboss.ejb.plugins.cmp.ejbql, org.jboss.logmanager.log4j.filters, org.jboss.remoting.transport.local, org.jboss.cache.invalidation.bridges, org.jaxen.dom, com.arjuna.common.internal.util.logging.jakarta, com.arjuna.ats.arjuna.gandiva, org.omg.CosNotifyComm, org.jboss.cache.loader.bdbje, org.jboss.xnio.channels, org.jboss.ejb3.common.kernel, org.jboss.remoting.marshal.http, org.omg.CONV_FRAME, com.arjuna.ats.arjuna.tools, bsh.util, org.jboss.ejb.plugins, org.apache.log4j.lf5.viewer.categoryexplorer, org.jboss.ejb.txtimer, org.omg.IIOP, org.jboss.serial.references, javax.xml.rpc.handler, org.omg.CosCollection, org.jgroups.blocks, net.jcip.annotations, org.jboss.ejb3.pool, org.hibernate.hql.ast.util, org.jboss.mx.remoting.connector, org.jboss.security.negotiation, org.jboss.security.auth.callback, org.jboss.metadata.annotation.creator.ejb, org.apache.commons.collections.comparators, org.jboss.ejb3.stateless, org.jgroups.protocols, com.arjuna.ats.internal.jdbc.drivers.modifiers, org.jboss.remoting.samples.detection.jndi, org.jboss.ejb3.interceptors.aop.annotation, com.arjuna.ats.arjuna.logging, org.jboss.ejb3.annotation.impl, org.jboss.cache.pojo.interceptors.dynamic, org.jboss.ejb3.mdb.inflow, org.jboss.security.negotiation.spnego, org.jboss.security.authorization.modules.ejb, org.jboss.proxy, org.omg.ATLAS, javax.servlet.resources, org.jboss.cache.interceptors, org.jboss.remoting.samples.chat.server, org.jboss.jms.jndi, org.jboss.aspects.txlock, org.jboss.remoting.transport.https, org.jboss.security.xacml.sunxacml.attr, org.jboss.iiop.csiv2, org.quartz.impl.jdbcjobstore.oracle.weblogic, org.jboss.cache.batch, org.jboss.remoting.transport.coyote.ssl, javax.el, org.jaxen.xom, META-INF.maven.org.jboss.ejb3.jboss-ejb3-metadata, javax.management.j2ee.statistics, com.arjuna.ats.internal.jbossatx.agent, META-INF.maven.org.jboss.javaee.jboss-jaspi-api, org.omg.CORBA.ContainerPackage, org.jboss.ws, com.arjuna.ats.internal.arjuna.gandiva.inventory, org.jboss.ejb3.service, org.jacorb.util.threadpool, config-samples, org.jboss.remoting.samples.chat.client, org.jboss.metadata.validation.validator.ejb, org.jboss.cache.optimistic, org.jboss.ha.framework.server.managed, org.hibernate.ejb.util, org.hibernate.ejb, org.jboss.security.plugins.auth, org.hibernate.dialect.function, org.jboss.cache.io, META-INF.maven.org.jboss.cache.jbosscache-pojo, org.jboss.invocation.http.interfaces, com.arjuna.ats.arjuna.recovery, org.quartz.impl.jdbcjobstore, schema, org.jboss.messaging.core.impl.postoffice, org.jboss.security.authorization, org.jboss.ejb3.cache.simple, META-INF.maven.org.jboss.ejb3.jboss-ejb3-core, org.jboss.ejb3.interceptors.annotation.impl, org.jboss.monitor.services, org.jacorb.sasPolicy, com.arjuna.ats.internal.jbossatx.jts.jca, META-INF.maven.org.jboss.jbossas.jboss-as-security, org.jboss.cache.pojo.collection, org.jboss.profileservice.spi, META-INF.maven.org.jboss.threads.jboss-threads, org.jboss.remoting.socketfactory, org.jboss.profileservice.spi.types, org.apache.commons.collections.list, org.jboss.tm.iiop, com.arjuna.ats.arjuna.common, com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca, org.jboss.jms.server.recovery, org.hibernate.annotations.common.reflection.java.generics, antlr.actions.java, org.jboss.resource.deployment, org.jboss.annotation.ear, META-INF.maven.org.jboss.naming.jnpserver, org.jboss.ha.jndi.impl.jbc, org.hibernate.dialect.lock, org.jboss.remoting.transport.coyote, org.jboss.cache.pojo.impl, org.hibernate.proxy.dom4j, org.omg.CosNotifyChannelAdmin, javax.annotation, org.hibernate.pretty, org.jboss.remoting.transport.multiplex.utility, org.jboss.cache.commands.read, javax.resource, org.hibernate.util, javax.xml.ws.handler.soap, org.omg.CSI, org.jaxen.dom4j, org.jgroups.jmx.protocols.pbcast, org.jacorb.poa.gui.pm, org.jboss.jms.tx, org.jboss.remoting.util.socket, org.jacorb.ir.gui, org.jboss.jmx.connector.invoker.client, org.apache.avalon.framework.component, org.jboss.wsf.spi.management.recording, META-INF.maven.org.jboss.ws.native.jbossws-native-jaxws, org.jboss.ejb3.proxy.impl.factory.session.stateless, com.arjuna.ats.internal.arjuna.state, org.jboss.jpa.deployers, org.hibernate.proxy.pojo.cglib, org.jboss.cache.pojo.jmx, com.sun.mail.pop3, org.jboss.ha.framework.server.lock, org.jacorb.poa.policy, org.jboss.proxy.ejb, org.jboss.messaging.core.impl.memory, org.omg.CSIIOP, org.jboss.remoting.samples.transporter.custom.client, org.jacorb.notification.filter, org.jboss.cache.marshall, org.jboss.security.javaee, META-INF.maven.org.jboss.logging.jboss-logging-jdk, org.apache.log4j.ext, org.apache.bcel.verifier.statics, org.jboss.jms.client.container, org.jboss.metadata.rar.spec, org.jboss.ejb3.proxy.impl.factory.session.stateful, org.apache.bsf.util.event, org.slf4j, META-INF.maven.org.jboss.ejb3.jboss-ejb3-transactions, com.arjuna.common.internal.util.logging, org.jboss.serial.objectmetamodel.safecloning, org.jboss.remoting.samples.transporter.serialization.client, org.jboss.cache.invocation, org.omg.CosTime, org.jboss.logging.jdk.format, org.hibernate.ejb.packaging, org.jboss.ejb3.proxy.clustered.objectfactory.session, com.arjuna.orbportability.debug, javax.persistence.spi, bsh.classpath, org.jacorb.notification.util, com.arjuna.ats.tsmx, org.jboss.ejb.plugins.cmp.bridge, org.jboss.resource.metadata.repository, com.arjuna.ats.tsmx.logging, org.jboss.cache.invalidation, org.jboss.profileservice.aop, org.omg.CORBA.ORBPackage, com.arjuna.ats.internal.jta.transaction.jts, org.jgroups.stack, org.jacorb.orb.standardInterceptors, org.hibernate.cache.impl.bridge, org.jboss.remoting.network, org.jboss.ejb3.cache.impl, org.jboss.security.deployers, org.jboss.ejb3.naming.client.java, org.jboss.ha.jmx, org.jboss.cache.util.reflect, org.jboss.monitor.alarm, org.jacorb.orb.rmi, dtd, org.jboss.security.negotiation.ntlm, org.jboss.cache.commands, org.jboss.metadata.annotation.creator.web, META-INF.maven.org.jboss.aspects.jboss-transaction-aspects, org.jboss.jms.destination, org.jboss.remoting.samples.chat.exceptions, org.jboss.web.deployers, org.jboss.ejb.plugins.security, org.jboss.tm.usertx.interfaces, org.jacorb.notification.container, org.jboss.wsf.common.handler, META-INF.maven.org.jboss.ws.jbossws-spi, javax.servlet.jsp.el, org.jboss.cache.jmx.annotations, org.jboss.remoting.marshal.encryption, org.jboss.ejb3.entity, org.jboss.security.microcontainer.beans, org.jboss.jms.server.jbosssx, org.jboss.jms.client, org.omg.CORBA.ContainedPackage, org.jboss.ejb3.security.client, org.jboss.ha.framework.server, org.jboss.ejb.plugins.inflow, org.apache.log4j.jmx, org.apache.log4j.config, org.jboss.serial, org.jboss.xnio.log, org.jboss.resource.adapter.jdbc.jdk6, org.hibernate.tuple.entity, javax.xml.ws.addressing, org.jboss.tm.usertx.server, org.jacorb.ir.gui.typesystem.remote, META-INF.maven.org.jboss.jbossas.jboss-as-iiop, org.jboss.remoting.marshal.compress, org.jgroups.tests.perf, com.arjuna.ats.internal.jts.orbspecific.coordinator, org.jboss.security.annotation, META-INF.maven.org.jboss.ejb3.jboss-ejb3-deployers, com.arjuna.ats.internal.jta.transaction.arjunacore.jca, org.jboss.metadata.ear.jboss, org.jboss.injection, org.jboss.serial.persister, com.arjuna.ats.jta.exceptions, org.jboss.jms.message, org.hibernate.hql.classic, org.jboss.remoting.util, org.jboss.remoting.samples.transporter.simple, org.jboss.remoting.callback, org.quartz.jobs.ee.ejb, org.jboss.resource.statistic.pool, org.jacorb.orb, com.arjuna.ats.jta.logging, com.arjuna.ats.internal.jts.interposition.resources.arjuna, org.jboss.ejb3.mcint.annotationadaptor, org.hibernate.criterion, javax.transaction, javax.xml.soap, org.jboss.security.xacml.core.model.context, org.jboss.remoting.marshal.rmi, org.jboss.invocation.jrmp.interfaces, org.jboss.security.jacc, org.hibernate.tool.instrument, org.jacorb.orb.factory, org.apache.log4j, org.jboss.ejb3.proxy.clustered.objectfactory, org.jboss.cache.config.parsing, com.arjuna.ats.internal.jts.orbspecific.interposition, org.jacorb.orb.dsi, org.jboss.remoting.samples.transporter.basic.server, org.jboss.ejb3.annotation.defaults, org.jboss.mq.server.jmx, org.jboss.iiop.rmi, org.jboss.metadata.ear.spec, org.jacorb.ir.gui.typesystem, org.jboss.security.plugins, org.jboss.ejb3.proxy.impl, org.omg.CORBA.ValueDefPackage, org.jboss.security.negotiation.prototype, org.apache.commons.collections.bag, org.apache.log4j.chainsaw, org.opennms.protocols.snmp, org.jboss.deployment.spi.factories, org.jboss.security.mapping.config, org.jboss.aspects.remoting.interceptors.transport, org.jboss.wsf.common.injection.resolvers, org.omg.ETF, org.jboss.serial.classmetamodel, org.jacorb.ir.gui.remoteobject, org.jboss.logging.util, com.arjuna.ats.internal.arjuna.recovery, org.apache.bsf.util.event.generator, org.jboss.security.identity.plugins, org.apache.bcel, org.jboss.remoting.transport.http, org.omg.CORBA.portable, com.arjuna.orbportability.event, org.jboss.tm.usertx, org.jboss.remoting.marshall.encryption, org.jboss.cache.commands.legacy, org.jboss.security.auth.message, org.hibernate.loader.hql, org.hibernate.cache.jbc2.access, org.jboss.security.identity.extensions, META-INF.maven.org.jboss.ejb3.jboss-ejb3-common, javax.mail.search, org.jboss.metadata.web.spec, org.hibernate.metadata, org.jboss.security.auth.container.modules, org.jboss.deployment.spi, org.jboss.security.authorization.config, org.jboss.iiop.tm, org.jboss.ejb3.interceptors.util, org.jboss.wsf.framework.deployment, org.hibernate.property, org.jboss.remoting.samples.stream, org.jboss.cache.commands.legacy.read, javax.management.j2ee, org.jboss.mx.remoting.rmi, org.jboss.util, org.jboss.deployment.remoting, org.jnp.interfaces.jnp, org.hibernate.collection, org.jboss.management.j2ee.factory, org.hibernate.exception, org.jboss.wsf.spi.tools.cmd, org.jboss.cache.loader, org.omg.SecurityReplaceable, org.jboss.naming.client.java, org.jboss.cache.interceptors.base, com.sun.mail.util, org.jboss.metadata.rar.jboss.mcf, com.arjuna.orbportability.internal.orbspecific.versions, org.hibernate.param, org.jboss.wsf.spi.invocation.integration, com.arjuna.ats.arjuna.xa, org.jboss.jms.server.plugin, org.jboss.ejb.plugins.cmp.jdbc2.keygen, org.jboss.wsf.common.servlet, org.jboss.cache.commands.write, javax.servlet.jsp.resources, org.jboss.security.plugins.mapping, org.jboss.hibernate.session, org.jacorb.imr.util, org.omg.CosNaming, org.omg.CosNaming.NamingContextExtPackage, org.jboss.remoting.transport.sslbisocket, org.jacorb.imr.AdminPackage, com.sun.mail.imap.protocol, org.jboss.cache, com.arjuna.ats.internal.jts.interposition.resources.restricted, META-INF.maven.org.jboss.aspects.jboss-security-aspects, org.jboss.remoting.transport, org.jboss.jpa.spi, org.apache.bcel.classfile, com.arjuna.ats.internal.arjuna.utils, org.jboss.metadata.client.jboss, org.jboss.ejb3.stateful, antlr.ASdebug, org.omg.PortableServer.POAPackage, org.hibernate.tool.hbm2ddl, org.jboss.jms.referenceable, com.arjuna.ats.internal.jts.coordinator, com.arjuna.ats.arjuna.exceptions, org.hibernate.loader.custom.sql, org.jboss.remoting.samples.callback, com.arjuna.ats.internal.jts.recovery.transactions, com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors, org.jboss.ws.tools.ant, org.hsqldb.types, org.jacorb.security.ssl, org.jboss.iiop.codebase, META-INF.maven.org.hibernate.hibernate-jmx, org.apache.bcel.verifier, org.jboss.security.xacml.factories, org.jacorb.orb.diop, com.arjuna.ats.jdbc.logging, org.jboss.ha.timestamp, org.jboss.ejb.plugins.cmp.jdbc2.bridge, org.jaxen.saxpath, com.arjuna.orbportability.oa.core, antlr.debug, org.jboss.xnio, com.arjuna.common.util.propertyservice.plugins, org.jacorb.concurrency, org.jboss.metadata.process.chain, antlr.actions.csharp, org.jgroups.persistence, org.jboss.security.xacml.sunxacml.finder, org.jboss.remoting.security.domain, org.jacorb.orb.dns, org.jboss.ejb.plugins.cmp.jdbc.bridge, org.jacorb.naming.namemanager, org.jacorb.imr, org.jacorb.poa.gui.beans, org.omg.SecurityLevel1, org.jboss.iiop.rmi.ir, org.omg.SecurityLevel2, org.jboss.jms.server.selector, com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.coordinator, org.hibernate.annotations.common.annotationfactory, org.jboss.ejb3.security.bridge, org.jacorb.notification.queue, com.arjuna.ats.internal.jts.recovery, org.jboss.security.audit.config, org.jboss.remoting.transport.http.ssl, org.jboss.deployment.plugin, org.jboss.cache.mvcc, org.jboss.security.xacml.core.model.policy, org.apache.log4j.net, org.jboss.ejb3.tx.metadata, org.jboss.security.auth.certs, org.jboss.metadata.ejb.jboss.jndipolicy.plugins, antlr.actions.cpp, org.jboss.resource.metadata.mcf, licenses, org.jacorb.config, org.jboss.metadata.common.ejb, org.hibernate.event, javax.resource.spi.endpoint, org.jaxen.function.xslt, com.arjuna.orbportability.oa, org.jboss.ejb3.common.deployers.spi, com.arjuna.ats.internal.jts.context, javax.resource.spi.security, com.arjuna.ats.jts, org.hibernate.cfg.annotations, org.jboss.cache.statetransfer, org.jboss.ejb3.mcint.metadata.plugins, org.jacorb.orb.util, META-INF.maven.org.jboss.cluster.jboss-ha-server-cache-spi, org.omg.CosNotification, org.jboss.ejb3.proxy.impl.jndiregistrar, org.jboss.wsf.framework.management, org.jboss.ejb3.cache.grouped, org.jboss.metadata.javaee.support, org.jboss.ejb3.session, org.jacorb.ssl, org.jboss.remoting.transport.socket, org.quartz.ee.servlet, org.jboss.wsf.common.injection, org.jboss.logging.jdk.xml, org.jboss.security.negotiation.spnego.encoding, org.jboss.profileservice.remoting, com.arjuna.ats.jta, javax.xml.rpc.encoding, javax.enterprise.deploy.spi.factories, org.jboss.security.audit.providers, javax.annotation.security, org.jboss.remoting.transport.sslmultiplex, org.jboss.varia.scheduler, org.jboss.metadata.javaee.spec, org.jboss.logging, org.jboss.jdbc, org.omg.CosTransactions, com.arjuna.ats.internal.jdbc] <IMPORT-ALL>NON_EMPTY}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Wed Jul 29 18:27:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Jul 2009 18:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1691) JBM2 cluster
 fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1419189196.1248906449395.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1691:
-----------------------------------------

    Attachment: build.xml


adding a build.xml for the client part. Copy the libraries into ./lib

> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Clebert Suconic
>         Attachments: build.xml, cluster-nodes-config-files.zip, Jbm2ClusterTest-NodeA.zip, Jbm2ClusterTest-NodeB.zip
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 18:27:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 29 Jul 2009 18:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1691) JBM2
 cluster fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <608939126.1248906449596.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478161#action_12478161 ] 

Clebert Suconic commented on JBMESSAGING-1691:
----------------------------------------------

I will hold working on this issue until Abdel Adridi provides some guidance on how to run this.

Also: We have another task on the roadmap for soak tests anyway.

> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Clebert Suconic
>         Attachments: build.xml, cluster-nodes-config-files.zip, Jbm2ClusterTest-NodeA.zip, Jbm2ClusterTest-NodeB.zip
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 18:29:29 2009
From: jira-events at lists.jboss.org (Abdel Dridi (JIRA))
Date: Wed, 29 Jul 2009 18:29:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1691) JBM2
 cluster fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1888119930.1248906569234.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478162#action_12478162 ] 

Abdel Dridi commented on JBMESSAGING-1691:
------------------------------------------

To replicate the issue, please follow the below steps:

1. In a physical nodeA, configure a live JMB2 micro-container using attached clutered-configuration.
2. In an other physical nodeB, configure a live JBM2 micro-container
3. In NodeA  configure the backup server of Live-NodeB server
4. In NodeB configure the backup server of Live-NodeA server
5. NodeA and NodeB are connected with an Ethernet-cross-cable for fast access.
6. Setup both client project (eclipse project) - make sure that some micro-container/server/lib is in classpath - I forgot to add them to lib.
7. In NodeA run the Junit test case "TestLauncher.testTenantPool()" of eclipse project Jbm2ClusterTest-NodeA.zip.
8. In NodeB run the Junit test case "TestLauncher.testTenantPool()" of eclipse project Jbm2ClusterTest-NodeB.zip.
9. After some time consumer connection will fail after packet-sent timeout - Problem1.
10. then Backup-server will kick-off while Live-server still have live connections which leads to Problem2: more than one broadcasters on the network broadcasting the same node id.
11. I attached a pic of the test case.



> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Clebert Suconic
>         Attachments: build.xml, cluster-nodes-config-files.zip, Jbm2ClusterTest-NodeA.zip, Jbm2ClusterTest-NodeB.zip
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 18:31:29 2009
From: jira-events at lists.jboss.org (Abdel Dridi (JIRA))
Date: Wed, 29 Jul 2009 18:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1691) JBM2 cluster
 fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1132067855.1248906689279.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Abdel Dridi updated JBMESSAGING-1691:
-------------------------------------

    Attachment: jbmTest.JPG


> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Clebert Suconic
>         Attachments: build.xml, cluster-nodes-config-files.zip, Jbm2ClusterTest-NodeA.zip, Jbm2ClusterTest-NodeB.zip, jbmTest.JPG
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 18:33:41 2009
From: jira-events at lists.jboss.org (Rob Stryker (JIRA))
Date: Wed, 29 Jul 2009 18:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMICROCONT-447) Allow changing
 timestamp on a deployment root folder (blah.war) to redeploy
Message-ID: <372720627.1248906821327.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Allow changing timestamp on a deployment root folder (blah.war) to redeploy
---------------------------------------------------------------------------

                 Key: JBMICROCONT-447
                 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-447
             Project: JBoss Microcontainer
          Issue Type: Feature Request
          Components: Deployment
            Reporter: Rob Stryker
            Assignee: Ales Justin


If I execute the following, JBoss 5.1 doesn't redeploy a module even though its clearly new. (assuming the module has no descriptor file required)

cd server/default/deploy
rm -rf some.war &&  cp -R /home/rob/tmp/some.war .

Clearly the entire project was removed and a new version coppied over, however the server has not recognized it as new because there is no descriptor. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 18:46:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 18:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-148) DocumentUtil
 transformer output properties
Message-ID: <2080437295.1248907589597.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

DocumentUtil transformer output properties
------------------------------------------

                 Key: JBID-148
                 URL: https://jira.jboss.org/jira/browse/JBID-148
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha4
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1


transformer.setOutputProperty(OutputKeys.INDENT, "no");


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 18:48:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 18:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-148) DocumentUtil
 transformer output properties
In-Reply-To: <2080437295.1248907589597.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2136802067.1248907709774.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-148.
------------------------------

    Resolution: Done


> DocumentUtil transformer output properties
> ------------------------------------------
>
>                 Key: JBID-148
>                 URL: https://jira.jboss.org/jira/browse/JBID-148
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>
> transformer.setOutputProperty(OutputKeys.INDENT, "no");

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 18:51:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 18:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-149)
 SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
Message-ID: <570484675.1248907889150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
-----------------------------------------------------------------------

                 Key: JBID-149
                 URL: https://jira.jboss.org/jira/browse/JBID-149
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
    Affects Versions: IDFED-1.0.0.alpha4
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 18:51:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Wed, 29 Jul 2009 18:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-149)
 SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
In-Reply-To: <570484675.1248907889150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <525249845.1248907889271.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-149.
------------------------------

    Resolution: Done


> SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
> -----------------------------------------------------------------------
>
>                 Key: JBID-149
>                 URL: https://jira.jboss.org/jira/browse/JBID-149
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.beta1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 18:55:44 2009
From: jira-events at lists.jboss.org (Noam Malki (JIRA))
Date: Wed, 29 Jul 2009 18:55:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7134) Modifying
 ManagedOperation to return either a composite value containing a Boolean
 and a String
Message-ID: <600159312.1248908144670.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Modifying ManagedOperation to return either a composite value containing a Boolean and a String
-----------------------------------------------------------------------------------------------

                 Key: JBAS-7134
                 URL: https://jira.jboss.org/jira/browse/JBAS-7134
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Noam Malki
            Assignee: Jesper Pedersen
            Priority: Minor


Returning a composite value containing a Boolean and a String would be useful.

For example, when invoking a test operation it would be useful to get a String  with the specific failure message if the operation failed (please see JOPR-324).


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 19:07:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 19:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7135) Rotated log ends up
 in the wrong directory
Message-ID: <553423281.1248908849311.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Rotated log ends up in the wrong directory
------------------------------------------

                 Key: JBAS-7135
                 URL: https://jira.jboss.org/jira/browse/JBAS-7135
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Logging
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: JBossAS-6.0.0.Alpha1


E.g. server.log.2009.07.26 will be in the directory from which run.sh was executed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 19:09:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 19:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-25) Logging error at
	midnight
Message-ID: <613160271.1248908969362.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Logging error at midnight
-------------------------

                 Key: JBLOGGING-25
                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-25
             Project: JBoss Logging
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: jboss-logmanager
    Affects Versions: 1.1.0.CR5-jboss-logmanager
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 1.1.0.CR6-jboss-logmanager


At midnight, an error occurs because the writer field is read before the pre-log hook and not rechecked in WriterHandler.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 19:09:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 19:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-26) Rotated log ends
 up in the wrong directory
Message-ID: <222944922.1248908969433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Rotated log ends up in the wrong directory
------------------------------------------

                 Key: JBLOGGING-26
                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-26
             Project: JBoss Logging
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: jboss-logmanager
    Affects Versions: 1.1.0.CR5-jboss-logmanager
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 1.1.0.CR6-jboss-logmanager


E.g. server.log.2009.07.26 will be in the directory from which run.sh was executed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 19:30:29 2009
From: jira-events at lists.jboss.org (Abdel Dridi (JIRA))
Date: Wed, 29 Jul 2009 19:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1691) JBM2 cluster
 fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <437808957.1248910229225.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Abdel Dridi updated JBMESSAGING-1691:
-------------------------------------

    Attachment: build.xml


updated build.xml and attached lib.zip that includes all used libs

> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Clebert Suconic
>         Attachments: build.xml, build.xml, cluster-nodes-config-files.zip, Jbm2ClusterTest-NodeA.zip, Jbm2ClusterTest-NodeB.zip, jbmTest.JPG
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 19:32:29 2009
From: jira-events at lists.jboss.org (Abdel Dridi (JIRA))
Date: Wed, 29 Jul 2009 19:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1691) JBM2 cluster
 fails under heavy load
In-Reply-To: <156609170.1248458849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1331625132.1248910349242.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Abdel Dridi updated JBMESSAGING-1691:
-------------------------------------

    Attachment: lib.zip


updated build.xml and attached lib.zip that includes all used libs

> JBM2 cluster fails under heavy load
> -----------------------------------
>
>                 Key: JBMESSAGING-1691
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1691
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 2.0.0.beta4
>         Environment: Linux-debian 64bits 8G RAM - Java1.6 update14 
>            Reporter: Abdel Dridi
>            Assignee: Clebert Suconic
>         Attachments: build.xml, build.xml, cluster-nodes-config-files.zip, Jbm2ClusterTest-NodeA.zip, Jbm2ClusterTest-NodeB.zip, jbmTest.JPG, lib.zip
>
>
> I have a cluster of 2 nodes; A and B:
> In nodeA, I have JMB2-NodeA-live and JBM2-NodeB-backup.
> In nodeB, I have JMB2-NodeB-live and JBM2-NodeA-backup.
> I have a client running in NodeA (eclipseProject "Jbm2ClusterTest-NodeA.zip") and an other client running in NodeB (eclipseProject "Jbm2ClusterTest-NodeB.zip") - Both client starts on the same time.
> In each project there's a Junit testcase (TestLauncher.testTenantPool) to start the test.
> I also attached the configuration (config/stand-alone/clustered) for each node (Live/Backup).
> BTW; I tried with the trunk build (07-23-2009) and JBM2-Beta3.
> I faced the following issues:
> Connection failure after producing 600k and consuming 400K messages of the InboundQueue in each node.
> If the failover kick off then after few min both BackUp and Live servers will be listening to the cluster which leads to "more than one broadcasters on the network broadcasting the same node id".
> I also see "failed to accept connection: too many open files".
> Let me know if you have any question,
> Abdel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 20:30:29 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Wed, 29 Jul 2009 20:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2199)
 NullPointerException with JPA session persistence in Drools Flow
In-Reply-To: <233050457.1247060645508.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1677063956.1248913829297.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen reassigned JBRULES-2199:
---------------------------------------

    Assignee: Kris Verlaenen  (was: Mark Proctor)


> NullPointerException with JPA session persistence in Drools Flow
> ----------------------------------------------------------------
>
>                 Key: JBRULES-2199
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2199
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Alan Gairey
>            Assignee: Kris Verlaenen
>
> I'm currently using Drools Flow with JPA session persistence enabled as described in section 5.1 of the User Guide.
> As a process executes, session information is saved to the H2 database correctly.
> The problem comes when recreating a session from its persisted state, using the code:
> {code}
> // recreate the session from database using the sessionId
> ksession = JPAKnowledgeService.loadStatefulKnowledgeSession( sessionId, kbase, null, env );
> {code}
> This gives me a NullPointerException.
> Having looked into the Drools Flow source code, I think the problem is in the class drools-persistence-jpa\src\main\java\org\drools\persistence\session\SingleSessionCommandService.java.
> The 4th constructor of this class (starting line 132) is called as part of the loading of a knowledge session from the H2 database (i.e. via the code above); this in turn leads to the afterCompletion method of the inner class SynchronizationImpl being called. The final two lines of this method are:
> {code}
> ((JPAProcessInstanceManager) ((ReteooWorkingMemory) session).getProcessInstanceManager()).clearProcessInstances();
> ((JPAWorkItemManager) ((ReteooWorkingMemory) session).getWorkItemManager()).clearWorkItems();
> {code}
> However, when called via the route described above, the session member variable of SingleSessionCommandService has not been set, thus causing the NullPointerException.
> (Interestingly, running the unit tests for drools-persistence-jpa does result in a NullPointerException being thrown multiple times, although the tests are still listed as having passed.)
> I believe enclosing the above two lines as follows will fix the problem:
> {code}
> if (session != null) { 
>     ((JPAProcessInstanceManager) ((ReteooWorkingMemory) session).getProcessInstanceManager()).clearProcessInstances(); 
>     ((JPAWorkItemManager) ((ReteooWorkingMemory) session).getWorkItemManager()).clearWorkItems(); 
> } 
> {code}
> Also, in the 4th constructor of SingleSessionCommandService, after the session has been set, the following line needs to be added to ensure the session id is the same as the session info id:
> {code}
> ((ReteooStatefulSession) this.session).setId( this.sessionInfo.getId() );
> {code}
> (This line _is_ present at the end of the 3rd constructor - line 123.)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 20:38:29 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Wed, 29 Jul 2009 20:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2201) Rule got
 executed even does not satisfy LHS after firing an external event in Flow
In-Reply-To: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <314900502.1248914309243.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen reassigned JBRULES-2201:
---------------------------------------

    Assignee: Kris Verlaenen  (was: Mark Proctor)


> Rule got executed even does not satisfy LHS after firing an external event in Flow
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2201
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert), drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP SP3, Eclipse 3.4.2
>            Reporter: Kit Chan
>            Assignee: Kris Verlaenen
>            Priority: Critical
>
> I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 20:40:30 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Wed, 29 Jul 2009 20:40:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2201) Rule got
 executed even does not satisfy LHS after firing an external event in Flow
In-Reply-To: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <365313435.1248914430216.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478177#action_12478177 ] 

Kris Verlaenen commented on JBRULES-2201:
-----------------------------------------

Do you have a simple standalone example that could show this behavior?

> Rule got executed even does not satisfy LHS after firing an external event in Flow
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2201
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert), drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP SP3, Eclipse 3.4.2
>            Reporter: Kit Chan
>            Assignee: Kris Verlaenen
>            Priority: Critical
>
> I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 20:42:29 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Wed, 29 Jul 2009 20:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2141) In a rule flow,
 when the action is in MVEL, it is not possible to import classes
In-Reply-To: <5800231.1245931797780.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1810192402.1248914549296.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen reassigned JBRULES-2141:
---------------------------------------

    Assignee: Kris Verlaenen  (was: Mark Proctor)


> In a rule flow, when the action is in MVEL, it is not possible to import classes
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-2141
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2141
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-eclipse (flow)
>    Affects Versions: FUTURE
>            Reporter: Nicolas Heron
>            Assignee: Kris Verlaenen
>
> example : 
> -----------
> Long montant = (Long)context.getVariable("surimposition");
> System.out.println ("Surimposition : '" + montant + "'");
>  filter = new org.drools.runtime.ClassObjectFilter (fr.sopra.impot.Impot.class);
> java.util.Collection impots = context.getKnowledgeRuntime().getObjects(filter);
> if (impots.size()==1) {
> 	Impot impot = (Impot)impots.toArray()[0]; 
> 	impot.setMontantRedressement(montant);
> }
> ---------------
> it says  at design time : 
> Process 'ImpotProcess' [fr.sopra.impot.ImpotProcess]: Action node 'Traitement des resultats' [13] has invalid action: was expecting type: java.lang.Object; but found type: null.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 20:42:29 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Wed, 29 Jul 2009 20:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2118) comment makes
 Work Definition parser fail
In-Reply-To: <30166236.1244728976467.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1559627022.1248914549441.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen reassigned JBRULES-2118:
---------------------------------------

    Assignee: Kris Verlaenen  (was: Mark Proctor)


> comment makes Work Definition parser fail
> -----------------------------------------
>
>                 Key: JBRULES-2118
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2118
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-eclipse (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Eclipse
>            Reporter: Wolfgang Laun
>            Assignee: Kris Verlaenen
>
> See example in Drools Flow, section 8.2.1., Creating the Work Definition: The comment // add more work items here ... makes the parser fail when calling up the RuleFlow editor ("Could not parse work definitions ...: null")

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 21:22:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 21:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBLOGGING-25) Logging error at
	midnight
In-Reply-To: <613160271.1248908969362.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1577030956.1248916949420.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBLOGGING-25.
--------------------------------

    Resolution: Done


> Logging error at midnight
> -------------------------
>
>                 Key: JBLOGGING-25
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-25
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logmanager
>    Affects Versions: 1.1.0.CR5-jboss-logmanager
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 1.1.0.CR6-jboss-logmanager
>
>
> At midnight, an error occurs because the writer field is read before the pre-log hook and not rechecked in WriterHandler.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 21:22:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 21:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBLOGGING-26) Rotated log ends
 up in the wrong directory
In-Reply-To: <222944922.1248908969433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2061652705.1248916949518.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBLOGGING-26.
--------------------------------

    Resolution: Done


> Rotated log ends up in the wrong directory
> ------------------------------------------
>
>                 Key: JBLOGGING-26
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-26
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logmanager
>    Affects Versions: 1.1.0.CR5-jboss-logmanager
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 1.1.0.CR6-jboss-logmanager
>
>
> E.g. server.log.2009.07.26 will be in the directory from which run.sh was executed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 22:17:29 2009
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 29 Jul 2009 22:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2219) UrlResource needs
 to optionally have a cache for remote resources
Message-ID: <1264762667.1248920249480.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

UrlResource needs to optionally have a cache for remote resources
-----------------------------------------------------------------

                 Key: JBRULES-2219
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2219
             Project: JBoss Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-api
    Affects Versions: 5.0.1.FINAL
            Reporter: Michael Neale
            Assignee: Michael Neale
             Fix For: 5.1.0.M1


The knowledge agent uses UrlResource - which is fine for http and https - except when network is down. Would be nice to cache the resource so that it can use a "last known good" version. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 22:35:41 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 22:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBLOGGING-24) Add ability to
 cache logger instances
In-Reply-To: <109580682.1248831509140.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <856163700.1248921341556.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBLOGGING-24.
--------------------------------

    Resolution: Done


> Add ability to cache logger instances
> -------------------------------------
>
>                 Key: JBLOGGING-24
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-24
>             Project: JBoss Logging
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-jdk, jboss-logging-log4j, jboss-logging-spi
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 2.2.0.CR1-jboss-logging
>
>
> The present API/SPI does not allow logger instances to be cached and reused, which can cause unnecessary memory pressure by creating many identical objects.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 22:37:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 22:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBLOGGING-23) Add support for
 internationalization and localization with parameterized messages
In-Reply-To: <731548133.1248831389259.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <225946088.1248921449149.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBLOGGING-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBLOGGING-23.
--------------------------------

    Resolution: Done


> Add support for internationalization and localization with parameterized messages
> ---------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-23
>                 URL: https://jira.jboss.org/jira/browse/JBLOGGING-23
>             Project: JBoss Logging
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-jdk, jboss-logging-log4j, jboss-logging-spi
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 2.2.0.CR1-jboss-logging
>
>
> The logging API should support optional parameters E.g.:
>     /**
>      * Issue a log message with parameters and a throwable with a level of TRACE.
>      *
>      * @param loggerFqcn the logger class name
>      * @param message the message
>      * @param params the message parameters
>      * @param t the throwable
>      */
>    public void trace(String loggerFqcn, Object message, Object[] params, Throwable t) { ... }
> The logger factory method should allow specification of a resource bundle, e.g.:
>    Logger getLogger(String category, String resourceBundleName) { ... }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 22:43:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 22:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7136) Add complete support
 for internationalized/localized log messages
Message-ID: <89020645.1248921809430.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add complete support for internationalized/localized log messages
-----------------------------------------------------------------

                 Key: JBAS-7136
                 URL: https://jira.jboss.org/jira/browse/JBAS-7136
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Logging
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: JBossAS-6.0.0.Alpha1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 22:45:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Wed, 29 Jul 2009 22:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1664) Ordering Group
 is broken on server restart when messages are paged and reloaded
In-Reply-To: <13667621.1245656216866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <614424335.1248921929408.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1664.
-----------------------------------

    Resolution: Done


Done. 

We didn't use those special SQLs for each DB type, rather we use standard jdbc Statement.setFetchSize() to limit the mem usage at the JBM side.



> Ordering Group is broken on server restart when messages are paged and reloaded
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1664
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1664
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> When messages are paged into the DB and reloaded on server restart, the strict is broken.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 22:45:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 22:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7136) Add complete support
 for internationalized/localized log messages
In-Reply-To: <89020645.1248921809430.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1047065175.1248921929523.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBAS-7136.
-----------------------------

    Resolution: Done


> Add complete support for internationalized/localized log messages
> -----------------------------------------------------------------
>
>                 Key: JBAS-7136
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7136
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: JBossAS-6.0.0.Alpha1
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 22:45:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 22:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7135) Rotated log ends up
 in the wrong directory
In-Reply-To: <553423281.1248908849311.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1115196315.1248921929637.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBAS-7135.
-----------------------------

    Resolution: Done


> Rotated log ends up in the wrong directory
> ------------------------------------------
>
>                 Key: JBAS-7135
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7135
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> E.g. server.log.2009.07.26 will be in the directory from which run.sh was executed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 22:45:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 29 Jul 2009 22:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7133) Logging error at
	midnight
In-Reply-To: <1226095905.1248903869144.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2080462554.1248921929751.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed JBAS-7133.
-----------------------------

    Resolution: Done


> Logging error at midnight
> -------------------------
>
>                 Key: JBAS-7133
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7133
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>            Priority: Minor
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> At midnight, we get:
> LogManager error of type WRITE_FAILURE: Error writing log message
> java.io.IOException: Stream closed
> 	at sun.nio.cs.StreamEncoder.ensureOpen(StreamEncoder.java:26)
> 	at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:99)
> 	at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:116)
> 	at java.io.OutputStreamWriter.write(OutputStreamWriter.java:203)
> 	at java.io.Writer.write(Writer.java:140)
> 	at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:65)
> 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:59)
> 	at org.jboss.logmanager.Logger.logRaw(Logger.java:849)
> 	at org.slf4j.impl.Slf4jLogger.log(Slf4jLogger.java:68)
> 	at org.apache.commons.logging.impl.SLF4JLocationAwareLog.debug(SLF4JLocationAwareLog.java:120)
> 	at com.arjuna.common.internal.util.logging.jakarta.JakartaRelevelingLogger.debug(JakartaRelevelingLogger.java:172)
> 	at com.arjuna.common.internal.util.logging.LogNoi18nImpl.debug(LogNoi18nImpl.java:419)
> 	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:727)
> 	at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:412)
> ...because of an order-of-operations error in the base logmanager handler.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Jul 29 23:46:29 2009
From: jira-events at lists.jboss.org (Michael Neale (JIRA))
Date: Wed, 29 Jul 2009 23:46:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2219) UrlResource needs
 to optionally have a cache for remote resources
In-Reply-To: <1264762667.1248920249480.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <509285791.1248925589342.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Neale closed JBRULES-2219.
----------------------------------

    Resolution: Done


> UrlResource needs to optionally have a cache for remote resources
> -----------------------------------------------------------------
>
>                 Key: JBRULES-2219
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2219
>             Project: JBoss Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-api
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Michael Neale
>            Assignee: Michael Neale
>             Fix For: 5.1.0.M1
>
>
> The knowledge agent uses UrlResource - which is fine for http and https - except when network is down. Would be nice to cache the resource so that it can use a "last known good" version. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 00:01:29 2009
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Thu, 30 Jul 2009 00:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JASSIST-91) More modular
	packaging
In-Reply-To: <261113433.1248888149149.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <578240973.1248926489508.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JASSIST-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478186#action_12478186 ] 

Shigeru Chiba commented on JASSIST-91:
--------------------------------------

It is technically possible to minimize the size of the jar file by removing unnecessary components. 
However, the proxy generation needs bytecode generation at the back stage, so the effect would be
smaller than you expected.

> More modular packaging
> ----------------------
>
>                 Key: JASSIST-91
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-91
>             Project: Javassist
>          Issue Type: Feature Request
>            Reporter: Pete Muir
>            Assignee: Shigeru Chiba
>            Priority: Optional
>
> It would great if you could just take the bits of Javassist you need - for example, we only ever use the proxy generation facility, and don't need any of the bytecode generation.
> Motivation is simple - smaller dependencies (in jar file size).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 01:36:29 2009
From: jira-events at lists.jboss.org (Bill Culp (JIRA))
Date: Thu, 30 Jul 2009 01:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7137) MDBs dont register
 local-jndi-name when provided in jboss.xml
Message-ID: <1347556772.1248932189281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

MDBs dont register local-jndi-name when provided in jboss.xml
-------------------------------------------------------------

                 Key: JBAS-7137
                 URL: https://jira.jboss.org/jira/browse/JBAS-7137
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB3
    Affects Versions: JBossAS-5.1.0.GA
         Environment: WIndows, Java 1.6 huge fat fast machine with thousands of terabytes
            Reporter: Bill Culp
            Assignee: Carlo de Wolf


MDBs do not register a JNDI name at all even when local-jndi-name is specified in the jboss.xml and can only be looked up using jboss.j2ee:jar=foo, name=fooname, service=EJB3.

Also start stop destroy create methods as provided for EJB beans in JMX are not provided.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 03:05:29 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 30 Jul 2009 03:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6771) Typo in log
 message of WebServiceDeployerEJB.internalDeploy()
In-Reply-To: <15110409.1239539482895.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2072642806.1248937529210.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478197#action_12478197 ] 

Richard Opalka commented on JBAS-6771:
--------------------------------------

It's not there any more. But we have to wait until JBossWS 3.2.0.Beta2 release is pushed to AS source base to close this issue.

> Typo in log message of WebServiceDeployerEJB.internalDeploy()
> -------------------------------------------------------------
>
>                 Key: JBAS-6771
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6771
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-5.0.1.GA
>            Reporter: Hiranya Samarasekera
>            Assignee: Richard Opalka
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> The word "Ignore" is mistyped as "Ingore" in the log message in method internalDeploy()
> log.warn("Ingore ejb deployment with null classname: " + ejb);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 03:18:29 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 30 Jul 2009 03:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7137) MDBs dont register
 local-jndi-name when provided in jboss.xml
In-Reply-To: <1347556772.1248932189281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1837885673.1248938309219.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved JBAS-7137.
---------------------------------

    Resolution: Rejected


MDBs don't have a local business interface, so there are no proxies bound in JNDI.

MDBs are not service MBeans, so they don't have the magic create/start/stop/destroy methods.

Please open a forum post if you want to discuss new use cases.

> MDBs dont register local-jndi-name when provided in jboss.xml
> -------------------------------------------------------------
>
>                 Key: JBAS-7137
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7137
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: WIndows, Java 1.6 huge fat fast machine with thousands of terabytes
>            Reporter: Bill Culp
>            Assignee: Carlo de Wolf
>
> MDBs do not register a JNDI name at all even when local-jndi-name is specified in the jboss.xml and can only be looked up using jboss.j2ee:jar=foo, name=fooname, service=EJB3.
> Also start stop destroy create methods as provided for EJB beans in JMX are not provided.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 03:40:29 2009
From: jira-events at lists.jboss.org (Atul Kumar (JIRA))
Date: Thu, 30 Jul 2009 03:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-759) CLONE -Unable to
 add package after it was added and removed
In-Reply-To: <29684385.1175171941888.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <817587266.1248939629369.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478202#action_12478202 ] 

Atul Kumar commented on JBRULES-759:
------------------------------------

Hi,
 I am using drools 4.0.7 for my applicaiton.

i am getting the same  issue in 

ruleBase.addPackage(rulePackage) method 

when there is multiple drl files with same package name at the provided location.

this does not happen when i use drools 4.0.4 or even drools 5.0.1 version

is this a bug that got introduced in the version 4.0.7  or i am missing something?

we are suppose to evaluate and use 4.0.7 version,

 so wanted to know that whether this issues which was there is 3.0x again reopened in 4.0.7.


> CLONE -Unable to add package after it was added and removed
> -----------------------------------------------------------
>
>                 Key: JBRULES-759
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-759
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 3.0.4
>         Environment: Windows2000 Advanced Server
> JBRules3.0.4
>            Reporter: Brugger Antony
>            Assignee: Edson Tirelli
>             Fix For: 3.0.7, 4.0.0.MR2
>
>
> Unable remove a rule package when it was added after it has been added and removed.
> I have seen the issue  [#JBRULES-358].  My test go a little far than [#JBRULES-358]. 
> I remove the package again when it was added for the seconn time, then an exception was thrown.
>  My test case is:
>     
>     public void testRuleBaseRemove() throws Exception
>     {
>         RuleBase ruleBase = RuleBaseFactory.newRuleBase();
>         File file = new File("test.drl");
>         
>         //add and remove
>         PackageBuilder builder = new PackageBuilder();
>         builder.addPackageFromDrl(new FileReader(file));
>         Package pkg = builder.getPackage();
>         ruleBase.addPackage(pkg);
>         ruleBase.removePackage(pkg.getName());
>         
>         //add and remove again
>         builder = new PackageBuilder();
>         builder.addPackageFromDrl(new FileReader(file));
>         pkg = builder.getPackage();
>         ruleBase.addPackage(pkg);
>         ruleBase.removePackage(pkg.getName());
>     }
> the exception is throw:
> java.lang.NullPointerException
> 	at org.drools.reteoo.HashedObjectSinkList.remove(HashedObjectSinkList.java:102)
> 	at org.drools.reteoo.ObjectTypeNode.remove(ObjectTypeNode.java:245)
> 	at org.drools.reteoo.AlphaNode.remove(AlphaNode.java:211)
> 	at org.drools.reteoo.AlphaNode.remove(AlphaNode.java:211)
> 	at org.drools.reteoo.LeftInputAdapterNode.remove(LeftInputAdapterNode.java:285)
> 	at org.drools.reteoo.TerminalNode.remove(TerminalNode.java:297)
> 	at org.drools.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:589)
> 	at org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:244)
> 	at org.drools.common.AbstractRuleBase.removePackage(AbstractRuleBase.java:338)
> 	at com.zte.ums.uep.pal.fm.osf.rules.core.RuleBaseTest.testRuleBaseRemove(RuleBaseTest.java:71)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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 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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 04:00:29 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 30 Jul 2009 04:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1703) SLSB pooling
 statistics misleading when using ThreadLocalPool
In-Reply-To: <9489125.1233153944280.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1261682643.1248940829696.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf reassigned EJBTHREE-1703:
---------------------------------------

    Assignee: Carlo de Wolf


> SLSB pooling statistics misleading when using ThreadLocalPool
> -------------------------------------------------------------
>
>                 Key: EJBTHREE-1703
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1703
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: pool
>    Affects Versions: AS 4.2.3.GA, 1.0.0-GA
>            Reporter: Galder Zamarreno
>            Assignee: Carlo de Wolf
>            Priority: Critical
>
> SLSB pooling statistics are hugely misleading when using default ThreadLocalPool:
> "The default pooling strategy used by EJB3 SLSBs is a ThreadLocalPool whose maximum is not really 
> quantifiable. The maximum is the maximum number of concurrent threads talking to that EJB3 SLSB 
> that the system can allocate. So, the MaxSize that you see in that JMX view is bogus at least for its 
> current definition of maximum.
> MaxSize - AvailableCount will give you the number of EJB3 SLSBs currently in use, in your case, 0. Again, 
> the meaning of AvailableCount for this pool strategy is not precise.
> CreateCount does represent the number of EJB3 SLSBs that have been created.
> CurrentSize is a bit more complicated to explain. For each thread that uses an EJB3 SLSBs, thread local 
> pool maintains a pool per each thread where there's an instance active in case it's needed again. So, 
> CurrentSize indicates how many of these active instances there are, which assuming that each thread 
> uses only one instance of the bean, matches the number of instances that have been created."
> Example:
> AvailableCount 	int 	R 	30 	MBean Attribute.
> MaxSize 	                int 	R 	30 	MBean Attribute.
> StateString 	        java.lang.String 	R 	Started 	MBean Attribute.
> State 	                int 	R 	3 	MBean Attribute.
> CurrentSize 	        int 	R 	165 	MBean Attribute.
> CreateCount 	        int 	R 	165 	MBean Attribute.
> RemoveCount 	        int 	R 	0 	MBean Attribute.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 04:17:29 2009
From: jira-events at lists.jboss.org (Mirek Sz (JIRA))
Date: Thu, 30 Jul 2009 04:17:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1878) Injection
 SessionContext in interceptor by ejb-jar.xml
Message-ID: <1400634977.1248941849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Injection SessionContext in interceptor by ejb-jar.xml
------------------------------------------------------

                 Key: EJBTHREE-1878
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1878
             Project: EJB 3.0
          Issue Type: Bug
          Components: injection
    Affects Versions: AS 5.0.0.CR1
         Environment: JBOSS 5.0.0 GA JAVA 1.6_014
            Reporter: Mirek Sz


When I try inject SessionContext by @Resource annotation everything works fine but when I inject it by ejb-jar.xml file I get following error 

full stacttrace:
10:15:00,445 ERROR [FieldBeanProperty] failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
java.lang.IllegalArgumentException: Can not set javax.ejb.SessionContext field test.InterceptorTest.sessionContext to test.SimpleEjbImpl
	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146)
	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150)
	at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:37)
	at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:57)
	at java.lang.reflect.Field.set(Field.java:657)
	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:74)
	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	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.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
10:15:00,445 ERROR [STDERR] java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
10:15:00,446 ERROR [STDERR] 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:99)
10:15:00,446 ERROR [STDERR] 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
10:15:00,462 ERROR [STDERR] 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
10:15:00,462 ERROR [STDERR] 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
10:15:00,463 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10:15:00,463 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
10:15:00,463 ERROR [STDERR] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
10:15:00,463 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Method.java:597)
10:15:00,463 ERROR [STDERR] 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
10:15:00,463 ERROR [STDERR] 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
10:15:00,463 ERROR [StatefulSessionProxyFactoryBase] Could not obtain new Session ID from SFSB Container
javax.ejb.EJBException: java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:423)
	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	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.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
Caused by: java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:99)
	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
	... 15 more


interceptor class

public class InterceptorTest {

	SessionContext sessionContext;
	public Object execute(InvocationContext invocation) throws Exception {
		System.out.println(invocation.getTarget());
		Context context = new InitialContext();
		return invocation.proceed();
	}
}


ejb-jar.xml fragment

<interceptor>
			<interceptor-class>test.InterceptorTest</interceptor-class>
			<around-invoke>
				<method-name>execute</method-name>
			</around-invoke>
			<resource-env-ref>
				<resource-env-ref-name>SessionContext</resource-env-ref-name>
				<resource-env-ref-type>javax.ejb.SessionContext</resource-env-ref-type>
				<injection-target>
					<injection-target-class>test.InterceptorTest</injection-target-class>
					<injection-target-name>sessionContext</injection-target-name>
				</injection-target>
			</resource-env-ref>
		</interceptor>




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 04:19:29 2009
From: jira-events at lists.jboss.org (Atul Kumar (JIRA))
Date: Thu, 30 Jul 2009 04:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2220) getting Issues
 with ruleBase.addPackage(rulePackage) in drools 4.0.7 where it works for
 drools4.0.4 and even drools 5.0.1
Message-ID: <1965023420.1248941969168.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

getting Issues with ruleBase.addPackage(rulePackage) in drools 4.0.7 where it works for drools4.0.4 and even drools 5.0.1
-------------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-2220
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2220
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core  (expert)
    Affects Versions: 4.0.7
         Environment: WindowsXP
            Reporter: Atul Kumar
            Assignee: Mark Proctor
             Fix For: 4.0.4


Hi, 
 I am using drools 4.0.7 for my applicaiton. 

i am getting the same issue in 

ruleBase.addPackage(rulePackage) method 

when there is multiple drl files with same package name at the provided location. 

this does not happen when i use drools 4.0.4 or even drools 5.0.1 version 

is this a bug that got introduced in the version 4.0.7 or i am missing something? 

we are suppose to evaluate and use 4.0.7 version, 

 so wanted to know that whether this issues which was there is 3.0x again reopened in 4.0.7. 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 04:23:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 30 Jul 2009 04:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1878) Injection
 SessionContext in interceptor by ejb-jar.xml
In-Reply-To: <1400634977.1248941849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1565711415.1248942209326.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned EJBTHREE-1878:
--------------------------------------

    Assignee: jaikiran pai


> Injection SessionContext in interceptor by ejb-jar.xml
> ------------------------------------------------------
>
>                 Key: EJBTHREE-1878
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1878
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: injection
>    Affects Versions: AS 5.0.0.CR1
>         Environment: JBOSS 5.0.0 GA JAVA 1.6_014
>            Reporter: Mirek Sz
>            Assignee: jaikiran pai
>
> When I try inject SessionContext by @Resource annotation everything works fine but when I inject it by ejb-jar.xml file I get following error 
> full stacttrace:
> 10:15:00,445 ERROR [FieldBeanProperty] failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> java.lang.IllegalArgumentException: Can not set javax.ejb.SessionContext field test.InterceptorTest.sessionContext to test.SimpleEjbImpl
> 	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146)
> 	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150)
> 	at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:37)
> 	at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:57)
> 	at java.lang.reflect.Field.set(Field.java:657)
> 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:74)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
> 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
> 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
> 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
> 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
> 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
> 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
> 10:15:00,445 ERROR [STDERR] java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> 10:15:00,446 ERROR [STDERR] 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:99)
> 10:15:00,446 ERROR [STDERR] 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
> 10:15:00,463 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 10:15:00,463 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 10:15:00,463 ERROR [STDERR] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 10:15:00,463 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Method.java:597)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
> 10:15:00,463 ERROR [StatefulSessionProxyFactoryBase] Could not obtain new Session ID from SFSB Container
> javax.ejb.EJBException: java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:423)
> 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
> 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
> Caused by: java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:99)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
> 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
> 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
> 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
> 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
> 	... 15 more
> interceptor class
> public class InterceptorTest {
> 	SessionContext sessionContext;
> 	public Object execute(InvocationContext invocation) throws Exception {
> 		System.out.println(invocation.getTarget());
> 		Context context = new InitialContext();
> 		return invocation.proceed();
> 	}
> }
> ejb-jar.xml fragment
> <interceptor>
> 			<interceptor-class>test.InterceptorTest</interceptor-class>
> 			<around-invoke>
> 				<method-name>execute</method-name>
> 			</around-invoke>
> 			<resource-env-ref>
> 				<resource-env-ref-name>SessionContext</resource-env-ref-name>
> 				<resource-env-ref-type>javax.ejb.SessionContext</resource-env-ref-type>
> 				<injection-target>
> 					<injection-target-class>test.InterceptorTest</injection-target-class>
> 					<injection-target-name>sessionContext</injection-target-name>
> 				</injection-target>
> 			</resource-env-ref>
> 		</interceptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 04:23:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 30 Jul 2009 04:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1566) Temporary
 Destinations should not allow their consumers to be created on other
 connections than their own as per JMS spec
In-Reply-To: <18089367.1238683225226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <328224984.1248942209573.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1566.
------------------------------------

    Resolution: Done
      Assignee: Jeff Mesnil  (was: Tim Fox)


fixed in the trunk

> Temporary Destinations should not allow their consumers to be created on other connections than their own as per JMS spec
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1566
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1566
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 2.0.0 Beta1
>            Reporter: Howard Gao
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> JMS 1.1 spec Section 4.4.3 2nd paragraph:
> Temporary destinations (TemporaryQueue or TemporaryTopic objects) are
> destinations that are system-generated uniquely for their connection. Only
> their own connection is allowed to create MessageConsumers for them.
> So the following test should fail, but currently it passes.
>    public void testTemporaryQueueScope()
>    {
>       try
>       {
>          senderConnection.stop();
>          receiverConnection.stop();
>          tempQueue = receiverSession.createTemporaryQueue();
>          //create consumer on different connection, should fail!
>          senderSession.createConsumer(tempQueue);
>       }
>       catch (JMSException e)
>       {
>          fail(e);
>       }
>    }
> The same issue exists with temporary topics too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 04:26:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 30 Jul 2009 04:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1878) Injection
 SessionContext in interceptor by ejb-jar.xml
In-Reply-To: <1400634977.1248941849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1821904932.1248942389172.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1878:
-----------------------------------

          Component/s: core
                           (was: injection)
    Affects Version/s: 1.0.0-Beta10
                           (was: AS 5.0.0.CR1)


> Injection SessionContext in interceptor by ejb-jar.xml
> ------------------------------------------------------
>
>                 Key: EJBTHREE-1878
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1878
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.0.0-Beta10
>         Environment: JBOSS 5.0.0 GA JAVA 1.6_014
>            Reporter: Mirek Sz
>            Assignee: jaikiran pai
>
> When I try inject SessionContext by @Resource annotation everything works fine but when I inject it by ejb-jar.xml file I get following error 
> full stacttrace:
> 10:15:00,445 ERROR [FieldBeanProperty] failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> java.lang.IllegalArgumentException: Can not set javax.ejb.SessionContext field test.InterceptorTest.sessionContext to test.SimpleEjbImpl
> 	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146)
> 	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150)
> 	at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:37)
> 	at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:57)
> 	at java.lang.reflect.Field.set(Field.java:657)
> 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:74)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
> 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
> 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
> 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
> 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
> 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
> 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
> 10:15:00,445 ERROR [STDERR] java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> 10:15:00,446 ERROR [STDERR] 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:99)
> 10:15:00,446 ERROR [STDERR] 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
> 10:15:00,463 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 10:15:00,463 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 10:15:00,463 ERROR [STDERR] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 10:15:00,463 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Method.java:597)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
> 10:15:00,463 ERROR [StatefulSessionProxyFactoryBase] Could not obtain new Session ID from SFSB Container
> javax.ejb.EJBException: java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:423)
> 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
> 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
> Caused by: java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:99)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
> 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
> 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
> 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
> 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
> 	... 15 more
> interceptor class
> public class InterceptorTest {
> 	SessionContext sessionContext;
> 	public Object execute(InvocationContext invocation) throws Exception {
> 		System.out.println(invocation.getTarget());
> 		Context context = new InitialContext();
> 		return invocation.proceed();
> 	}
> }
> ejb-jar.xml fragment
> <interceptor>
> 			<interceptor-class>test.InterceptorTest</interceptor-class>
> 			<around-invoke>
> 				<method-name>execute</method-name>
> 			</around-invoke>
> 			<resource-env-ref>
> 				<resource-env-ref-name>SessionContext</resource-env-ref-name>
> 				<resource-env-ref-type>javax.ejb.SessionContext</resource-env-ref-type>
> 				<injection-target>
> 					<injection-target-class>test.InterceptorTest</injection-target-class>
> 					<injection-target-name>sessionContext</injection-target-name>
> 				</injection-target>
> 			</resource-env-ref>
> 		</interceptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 04:28:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 30 Jul 2009 04:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1676) Jboss
	Messaging deadlock
In-Reply-To: <317741887.1246538691801.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1025128456.1248942509244.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478208#action_12478208 ] 

Howard Gao commented on JBMESSAGING-1676:
-----------------------------------------

Hi Daniel,

Along the stack there is no locking in JBM source code. It's probably from JCA.

Howard


> Jboss Messaging deadlock
> ------------------------
>
>                 Key: JBMESSAGING-1676
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1676
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: AS Integration
>    Affects Versions: 1.4.3.GA
>         Environment: Version:Linux 2.6.18-53.el5
> Description:Linux Operating System
> Traits
> OS Name: Linux
> OS Version: 2.6.18-53.el5
> Architecture: i386
> Distribution Name: CentOS
> Distribution Version: release 5 (Final)
>            Reporter: Daniel Cullender
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Under high concurrent load it appears that jboss messaging gets stuck in the Hashmap.put method which causes the threads to deadlock which in turn causes transaction timeouts.
> We have several mdb's which have max session sizes of 150, we have max strict pool size of 150 and the jboss thread pool size of 50.
> Recently upgraded from jboss AS 4 MQ series to jboss 5 AS with jboss messaging 1.4.3.GA, with JbossMQ  this problem did not occur.
> The stack trace of the problem is as follows :
> Thread: WorkManager(2)-50 : priority:5, demon:true, threadId:147,
> threadState:RUNNABLE
> java.util.HashMap.put(HashMap.java:374)
> java.util.HashSet.add(HashSet.java:200)
> org.jboss.jms.client.state.HierarchicalStateSupport.(HierarchicalStateSupport.java:63)
> org.jboss.jms.client.state.ProducerState.(ProducerState.java:68)
> org.jboss.jms.client.container.StateCreationAspect.handleCreateProducerDelegate(StateCreationAspect.java:180)
> org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateProducerDelegate_30485827.invoke(StateCreationAspect_z_handleCreateProducerDelegate_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.delegate.ClientSessionDelegate.createProducerDelegate(ClientSessionDelegate.java)
> org.jboss.jms.client.JBossSession.createProducer(JBossSession.java:209)
> qut.common.dao.JmsDao.publishMessage(JmsDao.java:66)
> qut.common.dao.JmsDao.publish(JmsDao.java:104)
> qut.order.manager.OrderManagerMBean.publish(OrderManagerMBean.java:156)
> qut.order.manager.OrderManagerMBean.process(OrderManagerMBean.java:98)
> sun.reflect.GeneratedMethodAccessor354.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
> sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
> org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:451)
> org.jboss.ejb3.service.ServiceMBeanDelegate.invoke(ServiceMBeanDelegate.java:215)
> org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> $Proxy1543.process(Unknown Source)
> qut.order.mdb.OrderManagerTradingDataMDBean.onMessage(OrderManagerTradingDataMDBean.java:64)
> sun.reflect.GeneratedMethodAccessor353.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor$InvocationContext.proceed(InvocationContextInterceptor.java:138)
> qut.common.interceptor.ConcurrencyInterceptor.myInterceptor(ConcurrencyInterceptor.java:46)
> sun.reflect.GeneratedMethodAccessor320.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:83)
> org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:70)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:59)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
> sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
> org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:80)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:282)
> org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:270)
> org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:140)
> $Proxy389.onMessage(Unknown Source)
> org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:178)
> org.jboss.jms.client.container.ClientConsumer.callOnMessageStatic(ClientConsumer.java:160)
> org.jboss.jms.client.container.SessionAspect.handleRun(SessionAspect.java:831)
> org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleRun_30485827.invoke(SessionAspect_z_handleRun_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.delegate.ClientSessionDelegate.run(ClientSessionDelegate.java)
> org.jboss.jms.client.JBossSession.run(JBossSession.java:199)
> org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:234)
> org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205)
> org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> java.lang.Thread.run(Thread.java:619)
> Locked synchronizers : 
> - locked <0x535d1e> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> Thread: WorkManager(2)-70 : priority:5, demon:true, threadId:168,
> threadState:RUNNABLE
> java.util.HashMap.put(HashMap.java:374)
> java.util.HashSet.add(HashSet.java:200)
> org.jboss.jms.client.state.HierarchicalStateSupport.(HierarchicalStateSupport.java:63)
> org.jboss.jms.client.state.ProducerState.(ProducerState.java:68)
> org.jboss.jms.client.container.StateCreationAspect.handleCreateProducerDelegate(StateCreationAspect.java:180)
> org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateProducerDelegate_30485827.invoke(StateCreationAspect_z_handleCreateProducerDelegate_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.delegate.ClientSessionDelegate.createProducerDelegate(ClientSessionDelegate.java)
> org.jboss.jms.client.JBossSession.createProducer(JBossSession.java:209)
> qut.common.dao.JmsDao.publishMessage(JmsDao.java:66)
> qut.common.dao.JmsDao.publish(JmsDao.java:104)
> qut.order.manager.OrderManagerMBean.publish(OrderManagerMBean.java:156)
> qut.order.manager.OrderManagerMBean.process(OrderManagerMBean.java:98)
> sun.reflect.GeneratedMethodAccessor354.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
> sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
> org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:451)
> org.jboss.ejb3.service.ServiceMBeanDelegate.invoke(ServiceMBeanDelegate.java:215)
> org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> $Proxy1384.process(Unknown Source)
> qut.order.mdb.OrderManagerTradingDataMDBean.onMessage(OrderManagerTradingDataMDBean.java:64)
> sun.reflect.GeneratedMethodAccessor353.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:69)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor$InvocationContext.proceed(InvocationContextInterceptor.java:138)
> qut.common.interceptor.ConcurrencyInterceptor.myInterceptor(ConcurrencyInterceptor.java:46)
> sun.reflect.GeneratedMethodAccessor320.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:83)
> org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:70)
> org.jboss.ejb3.EJBContainerInvocationWrapper.invokeNext(EJBContainerInvocationWrapper.java:59)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:73)
> org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:59)
> sun.reflect.GeneratedMethodAccessor287.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:597)
> org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_30485827.invoke(InvocationContextInterceptor_z_fillMethod_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
> org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_30485827.invoke(InvocationContextInterceptor_z_setup_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
> org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:80)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:282)
> org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:270)
> org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:140)
> $Proxy389.onMessage(Unknown Source)
> org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:178)
> org.jboss.jms.client.container.ClientConsumer.callOnMessageStatic(ClientConsumer.java:160)
> org.jboss.jms.client.container.SessionAspect.handleRun(SessionAspect.java:831)
> org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleRun_30485827.invoke(SessionAspect_z_handleRun_30485827.java)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
> org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> org.jboss.jms.client.delegate.ClientSessionDelegate.run(ClientSessionDelegate.java)
> org.jboss.jms.client.JBossSession.run(JBossSession.java:199)
> org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:234)
> org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205)
> org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> java.lang.Thread.run(Thread.java:619)
> Locked synchronizers : 
> - locked <0x18827b6> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 04:28:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 30 Jul 2009 04:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1878) Injection of
 SessionContext in interceptor by ejb-jar.xml fails
In-Reply-To: <1400634977.1248941849281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1792202565.1248942509368.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-1878:
-----------------------------------

                   Summary: Injection of SessionContext in interceptor by ejb-jar.xml fails  (was: Injection SessionContext in interceptor by ejb-jar.xml)
    Workaround Description: Using @Resource annotation in the interceptor class for SessionContext injection works. See the forum thread for details.
                Workaround: [Workaround Exists]


> Injection of SessionContext in interceptor by ejb-jar.xml fails
> ---------------------------------------------------------------
>
>                 Key: EJBTHREE-1878
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1878
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.0.0-Beta10
>         Environment: JBOSS 5.0.0 GA JAVA 1.6_014
>            Reporter: Mirek Sz
>            Assignee: jaikiran pai
>
> When I try inject SessionContext by @Resource annotation everything works fine but when I inject it by ejb-jar.xml file I get following error 
> full stacttrace:
> 10:15:00,445 ERROR [FieldBeanProperty] failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> java.lang.IllegalArgumentException: Can not set javax.ejb.SessionContext field test.InterceptorTest.sessionContext to test.SimpleEjbImpl
> 	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146)
> 	at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150)
> 	at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:37)
> 	at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:57)
> 	at java.lang.reflect.Field.set(Field.java:657)
> 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:74)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
> 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
> 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
> 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
> 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
> 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
> 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
> 10:15:00,445 ERROR [STDERR] java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> 10:15:00,446 ERROR [STDERR] 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:99)
> 10:15:00,446 ERROR [STDERR] 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
> 10:15:00,462 ERROR [STDERR] 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
> 10:15:00,463 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 10:15:00,463 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 10:15:00,463 ERROR [STDERR] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 10:15:00,463 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Method.java:597)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
> 10:15:00,463 ERROR [STDERR] 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
> 10:15:00,463 ERROR [StatefulSessionProxyFactoryBase] Could not obtain new Session ID from SFSB Container
> javax.ejb.EJBException: java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:423)
> 	at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:489)
> 	at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:637)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
> 	at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
> 	at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
> Caused by: java.lang.IllegalArgumentException: failed to set value org.jboss.ejb3.stateful.StatefulSessionContextImpl at 1687e27{containerGuid=jboss.j2ee:jar=TestEJB.jar,name=SimpleEjbImpl,service=EJB3,VMID=0c98273ef3885574:7112b98e:122cab903ab:-7f8f,id=5c4o201w-7cbr6j-fxr7llo3-1-fxr7n3od-9r} on field javax.ejb.SessionContext test.InterceptorTest.sessionContext
> 	at org.jboss.injection.lang.reflect.FieldBeanProperty.set(FieldBeanProperty.java:99)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:50)
> 	at org.jboss.injection.EJBContextPropertyInjector.inject(EJBContextPropertyInjector.java:45)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
> 	at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
> 	at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
> 	at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1076)
> 	at org.jboss.ejb3.stateful.StatefulContainer.create(StatefulContainer.java:136)
> 	at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:402)
> 	... 15 more
> interceptor class
> public class InterceptorTest {
> 	SessionContext sessionContext;
> 	public Object execute(InvocationContext invocation) throws Exception {
> 		System.out.println(invocation.getTarget());
> 		Context context = new InitialContext();
> 		return invocation.proceed();
> 	}
> }
> ejb-jar.xml fragment
> <interceptor>
> 			<interceptor-class>test.InterceptorTest</interceptor-class>
> 			<around-invoke>
> 				<method-name>execute</method-name>
> 			</around-invoke>
> 			<resource-env-ref>
> 				<resource-env-ref-name>SessionContext</resource-env-ref-name>
> 				<resource-env-ref-type>javax.ejb.SessionContext</resource-env-ref-type>
> 				<injection-target>
> 					<injection-target-class>test.InterceptorTest</injection-target-class>
> 					<injection-target-name>sessionContext</injection-target-name>
> 				</injection-target>
> 			</resource-env-ref>
> 		</interceptor>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 05:28:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 30 Jul 2009 05:28:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1017) GossipRouter:
 start() doesn't return - unit tests will block
Message-ID: <2025090477.1248946109242.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

GossipRouter: start() doesn't return - unit tests will block
------------------------------------------------------------

                 Key: JGRP-1017
                 URL: https://jira.jboss.org/jira/browse/JGRP-1017
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.8


We need to revert the change where we made start() call mainLoop() directly, this needs to run in a seperate thread. Or, we pass a boolean to start() which defines whether to call mainLoop() on a separate thread, or not.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 05:48:30 2009
From: jira-events at lists.jboss.org (Hans-Joerg Adel (JIRA))
Date: Thu, 30 Jul 2009 05:48:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JASSIST-83) NullPointerException
 in Handler#getType
In-Reply-To: <2275005.1244109956457.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <263565181.1248947310126.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JASSIST-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hans-Joerg Adel closed JASSIST-83.
----------------------------------



Everything ok.

> NullPointerException in Handler#getType
> ---------------------------------------
>
>                 Key: JASSIST-83
>                 URL: https://jira.jboss.org/jira/browse/JASSIST-83
>             Project: Javassist
>          Issue Type: Bug
>         Environment: JA version 3.4, Windows Vista and JDK 1.6.0_10
>            Reporter: Hans-Joerg Adel
>            Assignee: Shigeru Chiba
>            Priority: Optional
>             Fix For: 3.11.0.GA
>
>         Attachments: Sample.java, SampleClass.java
>
>
> Hi!
> When I use ExprEditor#edit(Handler) to access a try-statement without a catch-clause I get a NullPointerException. 
> To reproduce the bug, please use this source
> /*--- (C) 1999-2008 Techniker Krankenkasse ---*/
> package samplepackage;
> import javassist.CannotCompileException;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.NotFoundException;
> import javassist.expr.ExprEditor;
> import javassist.expr.Handler;
> public class Sample {
> 	public static void main(String[] args) throws NotFoundException, CannotCompileException {
> 		ClassPool classPool = ClassPool.getDefault();
> 		CtClass ctClass = classPool.get("samplepackage.SampleClass");
> 		ctClass.instrument(new MyExprEditor());
> 	}
> 	static class MyExprEditor extends ExprEditor {
> 		@Override
> 		public void edit(Handler h) throws CannotCompileException {
> 			try {
> 				h.getType();
> 			} catch (NotFoundException e) {
> 			}
> 		}
> 	}
> }
> Stacktrace:
> Exception in thread "main" java.lang.NullPointerException
> 	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:517)
> 	at javassist.bytecode.Descriptor.toCtClass(Descriptor.java:499)
> 	at javassist.expr.Handler.getType(Handler.java:76)
> 	at samplepackage.Sample$MyExprEditor.edit(Sample.java:25)
> 	at javassist.expr.ExprEditor.doit(ExprEditor.java:97)
> 	at javassist.CtClassType.instrument(CtClassType.java:1224)
> 	at samplepackage.Sample.main(Sample.java:17)
> I would expect that h.getType() returns null.
> I am using JA version 3.4, Windows Vista and JDK 1.6.0_10.
> Cheers
> Ruwen
> iA Hans-Joerg Adel

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 05:52:29 2009
From: jira-events at lists.jboss.org (Hans-Joerg Adel (JIRA))
Date: Thu, 30 Jul 2009 05:52:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-92) ExprEditor: edit
 "throw new Exception"-Statements
Message-ID: <19753949.1248947549788.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

ExprEditor: edit "throw new Exception"-Statements
-------------------------------------------------

                 Key: JASSIST-92
                 URL: https://jira.jboss.org/jira/browse/JASSIST-92
             Project: Javassist
          Issue Type: Feature Request
    Affects Versions: 3.11.0.GA
         Environment: WIndows Vista Java 1.6
            Reporter: Hans-Joerg Adel
            Assignee: Shigeru Chiba
            Priority: Minor


Hi!

At the moment I am using the ExprEditor. I miss an edit-Method to access throw statements like the follwing ones:

throw new RuntimeException();

try {
   foobar(x);
} catch (IllegalArgumentException e) {
   doSomething();
   throw e; // this statement
}


I think of something like this:

public void edit(ThrowExpr t) {
     t.getType(); // returns the CtClass of the thrown Exception
}

Cheers
Ruwen and Hans-Joerg

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 06:03:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 30 Jul 2009 06:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1561)
 ConnectionFactoryCallbackHandler$CallbackConnectionListener should call
 disconnectTimeout(0) in connection failure handling
In-Reply-To: <11075112.1238392560731.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <763518776.1248948209881.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard Gao closed JBMESSAGING-1561.
-----------------------------------

    Resolution: Done


In ClientClusteredConnectionFactoryDelegate.closeCallback() a boolean parameter is added to the method to indicate the reason for closing the callback. If this parameter is passed true, it calls remoting.setFailed() rather than stop().



> ConnectionFactoryCallbackHandler$CallbackConnectionListener should call disconnectTimeout(0) in connection failure handling
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1561
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1561
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP07, 1.4.2.GA.SP1
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> In ConnectionFactoryCallbackHandler$CallbackConnectionListener, the failure handling will close/stop the old remoting client and create/start a new one. The close/stop will call Client.disconnect() in the end. It should be called the Client.setDisconnectTimeout(0) before the disconnect call, so that the client will not attempt to do any remote calls in the closing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 06:15:29 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 30 Jul 2009 06:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-447) Create pom for
	testsuite
In-Reply-To: <22719663.1200604699244.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <508634577.1248948929986.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478219#action_12478219 ] 

Richard Opalka commented on JBBUILD-447:
----------------------------------------

Is the following failure somehow related to AS trunk build failure? I'm getting:

[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] An Ant BuildException has occured: The following error occurred while executing this line:
Target "dist" does not exist in the project "JBoss/Testsuite". 

and don't know wheter create new JIRA issue, or not?

> Create pom for testsuite
> ------------------------
>
>                 Key: JBBUILD-447
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-447
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> The testsuite module of the app server build needs a maven pom.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 06:15:30 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 30 Jul 2009 06:15:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-447) Create pom for
	testsuite
In-Reply-To: <22719663.1200604699244.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1876515937.1248948930106.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated JBBUILD-447:
-----------------------------------

    Comment: was deleted


> Create pom for testsuite
> ------------------------
>
>                 Key: JBBUILD-447
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-447
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> The testsuite module of the app server build needs a maven pom.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 06:15:30 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 30 Jul 2009 06:15:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-447) Create pom for
	testsuite
In-Reply-To: <22719663.1200604699244.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <663945383.1248948930238.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478220#action_12478220 ] 

Richard Opalka commented on JBBUILD-447:
----------------------------------------

Is the following failure somehow related to this issue? 

[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] An Ant BuildException has occured: The following error occurred while executing this line:
Target "dist" does not exist in the project "JBoss/Testsuite".

and don't know wheter create new JIRA issue, or not? 

> Create pom for testsuite
> ------------------------
>
>                 Key: JBBUILD-447
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-447
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> The testsuite module of the app server build needs a maven pom.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 07:02:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 30 Jul 2009 07:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-447) Create pom for
	testsuite
In-Reply-To: <22719663.1200604699244.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <125475898.1248951749306.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBBUILD-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478226#action_12478226 ] 

Paul Gier commented on JBBUILD-447:
-----------------------------------

The problem is related to JBBUILD-539.  It should be fixed now.

> Create pom for testsuite
> ------------------------
>
>                 Key: JBBUILD-447
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-447
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Maven Builds
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Maven Build - App Server (Phase 3)
>
>
> The testsuite module of the app server build needs a maven pom.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 07:07:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 30 Jul 2009 07:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1550) Core
 BridgeConfiguration with a discovery group is not deployed
In-Reply-To: <22813655.1237480462871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <492969544.1248952049200.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil closed JBMESSAGING-1550.
------------------------------------

    Resolution: Done


fixed in the trunk

> Core BridgeConfiguration with a discovery group is not deployed
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1550
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1550
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> A Core BridgeConfiguration can be set with either a discovery group or a pair of connectors.
> When the bridge is deployed (in ClusterManager.start()), we only check for the pair of connectors.
> If the bridge config uses a discovery group, it will never be deployed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 08:04:29 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 30 Jul 2009 08:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7138) Update JBossWS to
	3.2.0.GA
Message-ID: <1764228945.1248955469338.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Update JBossWS to 3.2.0.GA
--------------------------

                 Key: JBAS-7138
                 URL: https://jira.jboss.org/jira/browse/JBAS-7138
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Richard Opalka
            Assignee: Richard Opalka
             Fix For: JBossAS-5.2.0.Beta1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 08:36:29 2009
From: jira-events at lists.jboss.org (Bulat Nigmatullin (JIRA))
Date: Thu, 30 Jul 2009 08:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1018)
 TP.sendToSingleMember NullPointerException
Message-ID: <847418881.1248957389599.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

TP.sendToSingleMember NullPointerException
------------------------------------------

                 Key: JGRP-1018
                 URL: https://jira.jboss.org/jira/browse/JGRP-1018
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.8
         Environment: Ubuntu Linux 9.04 64-bit
            Reporter: Bulat Nigmatullin
            Assignee: Bela Ban


2009.07.30 16:28:47 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 2a1f5231-474b-aa1c-976d-70f5b32265af (108 bytes)
java.lang.NullPointerException
        at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
        at org.jgroups.protocols.TP.doSend(TP.java:1090)
        at org.jgroups.protocols.TP.send(TP.java:1073)
        at org.jgroups.protocols.TP.down(TP.java:934)
        at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
        at org.jgroups.protocols.Discovery.down(Discovery.java:411)
        at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
        at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
        at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
        at org.jgroups.protocols.FD.down(FD.java:300)
        at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:76)
        at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1436)
        at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1382)
        at org.jgroups.protocols.pbcast.NAKACK.stable(NAKACK.java:1354)
        at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:581)
        at org.jgroups.protocols.UNICAST.down(UNICAST.java:408)
        at org.jgroups.protocols.pbcast.STABLE.handleStabilityMessage(STABLE.java:622)
        at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:247)
        at org.jgroups.protocols.UNICAST.up(UNICAST.java:297)
        at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:823)
        at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:686)
        at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
        at org.jgroups.protocols.FD.up(FD.java:265)
        at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:271)
        at org.jgroups.stack.Protocol.up(Protocol.java:336)
        at org.jgroups.protocols.Discovery.up(Discovery.java:234)
        at org.jgroups.stack.Protocol.up(Protocol.java:336)
        at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
        at org.jgroups.protocols.TP.access$100(TP.java:53)
        at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
        at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
2009.07.30 16:28:58 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 38d9e5b6-4d65-20b4-7b41-7c6658e928d6 (172 bytes)
java.lang.NullPointerException
        at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
        at org.jgroups.protocols.TP.doSend(TP.java:1090)
        at org.jgroups.protocols.TP.send(TP.java:1073)
        at org.jgroups.protocols.TP.down(TP.java:934)
        at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
        at org.jgroups.protocols.Discovery.down(Discovery.java:411)
        at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
        at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
        at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
        at org.jgroups.protocols.FD.down(FD.java:300)
        at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
        at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
        at org.jgroups.protocols.FD.up(FD.java:265)
        at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
        at org.jgroups.stack.Protocol.up(Protocol.java:336)
        at org.jgroups.protocols.Discovery.up(Discovery.java:234)
        at org.jgroups.stack.Protocol.up(Protocol.java:336)
        at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
        at org.jgroups.protocols.TP.access$100(TP.java:53)
        at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
        at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 08:51:41 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 30 Jul 2009 08:51:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1018)
 TP.sendToSingleMember NullPointerException
In-Reply-To: <847418881.1248957389599.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1951757341.1248958301581.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1018:
---------------------------

    Fix Version/s: 2.8


> TP.sendToSingleMember NullPointerException
> ------------------------------------------
>
>                 Key: JGRP-1018
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1018
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.8
>         Environment: Ubuntu Linux 9.04 64-bit
>            Reporter: Bulat Nigmatullin
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> 2009.07.30 16:28:47 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 2a1f5231-474b-aa1c-976d-70f5b32265af (108 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:76)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1436)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1382)
>         at org.jgroups.protocols.pbcast.NAKACK.stable(NAKACK.java:1354)
>         at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:581)
>         at org.jgroups.protocols.UNICAST.down(UNICAST.java:408)
>         at org.jgroups.protocols.pbcast.STABLE.handleStabilityMessage(STABLE.java:622)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:247)
>         at org.jgroups.protocols.UNICAST.up(UNICAST.java:297)
>         at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:823)
>         at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:686)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:271)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> 2009.07.30 16:28:58 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 38d9e5b6-4d65-20b4-7b41-7c6658e928d6 (172 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 08:53:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 30 Jul 2009 08:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1018)
 TP.sendToSingleMember NullPointerException
In-Reply-To: <847418881.1248957389599.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <864111734.1248958409168.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478240#action_12478240 ] 

Bela Ban commented on JGRP-1018:
--------------------------------

Can you try this with the latest from CVS head ? sendToSingleMember() doesn't exist anymore, it is sendUnicast() now

> TP.sendToSingleMember NullPointerException
> ------------------------------------------
>
>                 Key: JGRP-1018
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1018
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.8
>         Environment: Ubuntu Linux 9.04 64-bit
>            Reporter: Bulat Nigmatullin
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> 2009.07.30 16:28:47 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 2a1f5231-474b-aa1c-976d-70f5b32265af (108 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:76)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1436)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1382)
>         at org.jgroups.protocols.pbcast.NAKACK.stable(NAKACK.java:1354)
>         at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:581)
>         at org.jgroups.protocols.UNICAST.down(UNICAST.java:408)
>         at org.jgroups.protocols.pbcast.STABLE.handleStabilityMessage(STABLE.java:622)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:247)
>         at org.jgroups.protocols.UNICAST.up(UNICAST.java:297)
>         at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:823)
>         at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:686)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:271)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> 2009.07.30 16:28:58 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 38d9e5b6-4d65-20b4-7b41-7c6658e928d6 (172 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 09:30:29 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 30 Jul 2009 09:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1703) SLSB pooling
 statistics misleading when using ThreadLocalPool
In-Reply-To: <9489125.1233153944280.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <166361289.1248960629720.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved EJBTHREE-1703.
-------------------------------------

    Fix Version/s: 1.1.11
       Resolution: Done


I've changed maxSize to dynamically adjust according to the number of threads using the ThreadlocalPool. Note that a reentrance means an extra addition to maxSize for the duration of the call. Or in other words: maxSize = createCount - removeCount.
This means that the equation: inUse = maxSize - availableCount will be valid from now on.

Initially maxSize and availableCount are 0 until the first call reaches the SLSB. Then maxSize becomes 1. AvailableCount will become 1 after the call finishes. Off course both values are bogus in relation to the ThreadlocalPool, because in actuality it can create an infinite amount of instances to service reentrant calls and other threads.

Again the real maximum size of the ThreadlocalPool is governed by the amount of threads calling upon the SLSB. If this is an unreasonable large number or the calls are coming from a thread factory instead of a thread pool, then StrictMaxPool must be used instead.

> SLSB pooling statistics misleading when using ThreadLocalPool
> -------------------------------------------------------------
>
>                 Key: EJBTHREE-1703
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1703
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: pool
>    Affects Versions: AS 4.2.3.GA, 1.0.0-GA
>            Reporter: Galder Zamarreno
>            Assignee: Carlo de Wolf
>            Priority: Critical
>             Fix For: 1.1.11
>
>
> SLSB pooling statistics are hugely misleading when using default ThreadLocalPool:
> "The default pooling strategy used by EJB3 SLSBs is a ThreadLocalPool whose maximum is not really 
> quantifiable. The maximum is the maximum number of concurrent threads talking to that EJB3 SLSB 
> that the system can allocate. So, the MaxSize that you see in that JMX view is bogus at least for its 
> current definition of maximum.
> MaxSize - AvailableCount will give you the number of EJB3 SLSBs currently in use, in your case, 0. Again, 
> the meaning of AvailableCount for this pool strategy is not precise.
> CreateCount does represent the number of EJB3 SLSBs that have been created.
> CurrentSize is a bit more complicated to explain. For each thread that uses an EJB3 SLSBs, thread local 
> pool maintains a pool per each thread where there's an instance active in case it's needed again. So, 
> CurrentSize indicates how many of these active instances there are, which assuming that each thread 
> uses only one instance of the bean, matches the number of instances that have been created."
> Example:
> AvailableCount 	int 	R 	30 	MBean Attribute.
> MaxSize 	                int 	R 	30 	MBean Attribute.
> StateString 	        java.lang.String 	R 	Started 	MBean Attribute.
> State 	                int 	R 	3 	MBean Attribute.
> CurrentSize 	        int 	R 	165 	MBean Attribute.
> CreateCount 	        int 	R 	165 	MBean Attribute.
> RemoveCount 	        int 	R 	0 	MBean Attribute.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 09:46:41 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 30 Jul 2009 09:46:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1556) Add
 additional core management notifications
In-Reply-To: <4089038.1237901302475.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <247681520.1248961601750.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned JBMESSAGING-1556:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> Add additional core management notifications
> --------------------------------------------
>
>                 Key: JBMESSAGING-1556
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1556
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 2.0.0
>
>
> Add additional management notifications for the following events in JBM server:
> 1/ notifications for start/stop of some messaging component: 
> - ACCEPTOR_STARTED / ACCEPTOR_STOPPED 
> - BRIDGE_STARTED / BRIDGE_STOPPED 
> - BROADCAST_GROUP_STARTED / BROADCAST_GROUP_STOPPED 
> - CLUSTER_CONNECTION_STARTED / CLUSTER_CONNECTION_STOPPED 
> - DISCOVERY_GROUP_STARTED / DISCOVERY_GROUP_STOPPED 
> 2/ I was also thinking to add notifications when messages are expired/moved to the dead letter address but I'm not sure these notifications should be enabled by default (they can potentially generate a lot of notifications): 
> EXPIRED_MESSAGE -> when a message is expired 
> MOVED_TO_DEAD_LETTER_ADDRESS -> when a message is moved to the DLA 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 10:00:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 10:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-217)
 ConfigPropertyMetaData has incorrect toString() implementation
Message-ID: <521983232.1248962429302.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

ConfigPropertyMetaData has incorrect toString() implementation
--------------------------------------------------------------

                 Key: JBMETA-217
                 URL: https://jira.jboss.org/jira/browse/JBMETA-217
             Project: JBoss Metadata
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Jesper Pedersen
            Assignee: Jeff Zhang
            Priority: Minor


ConfigPropertyMetaData has an incorrect toString() implementation.

Check if there are other classes that suffers from the same problem.

(Using trunk snapshot)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 10:03:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 10:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-218) Create common base
 class for all JCA 1.6 implementations
Message-ID: <1703984697.1248962609195.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Create common base class for all JCA 1.6 implementations
--------------------------------------------------------

                 Key: JBMETA-218
                 URL: https://jira.jboss.org/jira/browse/JBMETA-218
             Project: JBoss Metadata
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Jesper Pedersen
            Assignee: Jeff Zhang


Create a common base class for all the JCA 1.6 implementations, like

 JCA16Base

which contains the following:

   private boolean metadataComplete;
   private List<String> requiredWorkContexts;


   public boolean isMetadataComplete()
   {
      return metadataComplete;
   }

   @XmlAttribute(required=true)
   public void setMetadataComplete(boolean metadataComplete)
   {
      this.metadataComplete = metadataComplete;
   }

   public List<String> getRequiredWorkContexts()
   {
      return requiredWorkContexts;
   }

   @XmlElement(name = "required-work-context")
   public void setRequiredWorkContexts(List<String> requiredWorkContexts)
   {
      this.requiredWorkContexts = requiredWorkContexts;
   }

This will eliminate the need to type cast to each implementation specific class.

(Using trunk snapshot)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 10:06:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 10:06:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-133) Create bean
 validation handler class
Message-ID: <1820759790.1248962789155.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Create bean validation handler class
------------------------------------

                 Key: JBJCA-133
                 URL: https://jira.jboss.org/jira/browse/JBJCA-133
             Project: JBoss JCA
          Issue Type: Task
          Components: Standalone
            Reporter: Jesper Pedersen
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha3


Create a class that will handle the bean validation for the JCA 1.6 deployer chain.

The class should be called BeanValidation - located in sjc/src/main/java/org/jboss/jca/sjc/deployers/ra/ for now - and contain the method

  public static void validateObject(Object object) throws ConstraintViolationException


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 10:08:42 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 10:08:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-134) Make bean validation
	optional
Message-ID: <1719684468.1248962922045.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Make bean validation optional
-----------------------------

                 Key: JBJCA-134
                 URL: https://jira.jboss.org/jira/browse/JBJCA-134
             Project: JBoss JCA
          Issue Type: Task
          Components: Standalone
            Reporter: Jesper Pedersen
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha3


Make the bean validation optional in the deployer by making a property called beanValidation in RADeployer.

This property should be true by default, but can be overriding in boot.xml.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 10:12:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 10:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-135) Add support for
 additional bean validation groups
Message-ID: <145547166.1248963149145.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add support for additional bean validation groups
-------------------------------------------------

                 Key: JBJCA-135
                 URL: https://jira.jboss.org/jira/browse/JBJCA-135
             Project: JBoss JCA
          Issue Type: Task
          Components: Standalone
            Reporter: Jesper Pedersen
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha3


Extend our vendor specific deployment descriptor (jboss-ra.xml) with the possibility to add additional bean validation groups.

The jboss-ra.xml should contain functionality to specify f.ex.

 <bean-validation-groups>
   <bean-validation-group>com.mycompany.myproject.bv.Group1</bean-validation-group>
   <bean-validation-group>com.mycompany.myproject.bv.Group2</bean-validation-group>
 </bean-validation-groups>

where each token is a class name.

The metadata part of this task should be handled in JBMETA.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 10:24:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 10:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-136) JBoss Logging
	2.2.0.CR1
Message-ID: <797949956.1248963869163.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss Logging 2.2.0.CR1
-----------------------

                 Key: JBJCA-136
                 URL: https://jira.jboss.org/jira/browse/JBJCA-136
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha3




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 10:24:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 10:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-137) JBoss Logging
	Metadata 1.0.0.CR2
Message-ID: <748322675.1248963869227.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss Logging Metadata 1.0.0.CR2
--------------------------------

                 Key: JBJCA-137
                 URL: https://jira.jboss.org/jira/browse/JBJCA-137
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha3




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 10:26:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 10:26:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-138) JBoss LogManager
	1.1.0.CR6
Message-ID: <325491511.1248963989240.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBoss LogManager 1.1.0.CR6
--------------------------

                 Key: JBJCA-138
                 URL: https://jira.jboss.org/jira/browse/JBJCA-138
             Project: JBoss JCA
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Alpha3




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 10:44:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Thu, 30 Jul 2009 10:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1680) Improving
 the startup of Messaging Post Office service
In-Reply-To: <443833333.1247032268842.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <885834765.1248965069312.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478262#action_12478262 ] 

Howard Gao commented on JBMESSAGING-1680:
-----------------------------------------

I have measured the start-up time of three components of JBM: Server Peer, Messaging Office and GroupMember. The GroupMember is contained in the Messaging Office startup process. Using JBoss 4.2.3.GA, I tested the timing in three cases: single node non clustered with hsql, single node non clustered with mysql, and two nodes clustered with mysql. The result shows


1. The Messaging Office (and GroupMember in clustered case) takes much more longer time to start up in clustered case than in non-clustered case.
In single non-clustered case, Messaging Office takes very little time (e.g. 5ms or 31ms) to start. But in clustered case, it takes more than 6 sec
to start up, of which 98% to 99% are taken by GroupMember. Of the total startup time of GroupMember, around 98% are devoted to the connection of two jgroup channels. And between the two channels, the control channel takes about 30% of the time and the data channel takes about 65%. So if we can start the two channels concurrently, we may save some time.

See the data:

 Total duration: 6107  [GroupMember]
 -----------------------------------------------
 [create-control-channel] : dur 17 ---> 0.28%
 [create-data-channel] : dur 32 ---> 0.52%
 [connect-control-channel] : dur 2011 ---> 32.93%
 [connect-data-channel] : dur 4047 ---> 66.27%
 -----------------------------------------------
 Total duration: 6220  [Messaging PostOffice]
 -----------------------------------------------
 [super-start] : dur 15 ---> 0.24%
 [office-init] : dur 0 ---> 0.0%
 [get-bindings-from-storage] : dur 33 ---> 0.53%
 [groupmember-start] : dur 6118 ---> 98.36%
 [cluster-init] : dur 47 ---> 0.76%
 [load-bindings] : dur 7 ---> 0.11%
 -----------------------------------------------


2. In all cases the ServerPeer start takes a relative short and constant time (around 100ms), see the data:

a) Clustered case -- node0, it takes 99 ms

  Total duration: 99  [Server Peer]
  -----------------------------------------------
  [load-aop-config] : dur 30 ---> 30.3%
  [members-creation] : dur 45 ---> 45.45%
  [start-id-mgrs] : dur 16 ---> 16.16%
  [start-jndi-mappers] : dur 1 ---> 1.01%
  [start-conn-mgrs] : dur 5 ---> 5.05%
  [start-msg-store] : dur 0 ---> 0.0%
  [start-tx-repo] : dur 0 ---> 0.0%
  [loading-tx-repo] : dur 2 ---> 2.02%
  [start-msg-counters] : dur 0 ---> 0.0%
  -----------------------------------------------

b) Non clustered case -- mysql, it takes 101 ms

 Total duration: 101  [Server Peer]
 -----------------------------------------------
 [load-aop-config] : dur 32 ---> 31.68%
 [members-creation] : dur 43 ---> 42.57%
 [start-id-mgrs] : dur 23 ---> 22.77%
 [start-jndi-mappers] : dur 0 ---> 0.0%
 [start-conn-mgrs] : dur 2 ---> 1.98%
 [start-msg-store] : dur 0 ---> 0.0%
 [start-tx-repo] : dur 0 ---> 0.0%
 [loading-tx-repo] : dur 1 ---> 0.99%
 [start-msg-counters] : dur 0 ---> 0.0%
 -----------------------------------------------



> Improving the startup of Messaging Post Office service
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1680
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1680
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Investigating the possibility of starting the two JGroups channels concurrently so that the startup process will be faster.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 11:10:29 2009
From: jira-events at lists.jboss.org (Bulat Nigmatullin (JIRA))
Date: Thu, 30 Jul 2009 11:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1018)
 TP.sendToSingleMember NullPointerException
In-Reply-To: <847418881.1248957389599.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <346113145.1248966629179.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478265#action_12478265 ] 

Bulat Nigmatullin commented on JGRP-1018:
-----------------------------------------

Please, provide exact CVS checkout URL. I'm little confused trying to find out it.

> TP.sendToSingleMember NullPointerException
> ------------------------------------------
>
>                 Key: JGRP-1018
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1018
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.8
>         Environment: Ubuntu Linux 9.04 64-bit
>            Reporter: Bulat Nigmatullin
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> 2009.07.30 16:28:47 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 2a1f5231-474b-aa1c-976d-70f5b32265af (108 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:76)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1436)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1382)
>         at org.jgroups.protocols.pbcast.NAKACK.stable(NAKACK.java:1354)
>         at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:581)
>         at org.jgroups.protocols.UNICAST.down(UNICAST.java:408)
>         at org.jgroups.protocols.pbcast.STABLE.handleStabilityMessage(STABLE.java:622)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:247)
>         at org.jgroups.protocols.UNICAST.up(UNICAST.java:297)
>         at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:823)
>         at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:686)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:271)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> 2009.07.30 16:28:58 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 38d9e5b6-4d65-20b4-7b41-7c6658e928d6 (172 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 11:20:29 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 30 Jul 2009 11:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2099) Example source.
In-Reply-To: <25948784.1243417258146.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1799321103.1248967229194.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen reassigned JBRULES-2099:
---------------------------------------

    Assignee: Kris Verlaenen  (was: Mark Proctor)


> Example source.
> ---------------
>
>                 Key: JBRULES-2099
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2099
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP,eclipse
>            Reporter: gitae yang
>            Assignee: Kris Verlaenen
>             Fix For: 5.0.1.FINAL
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Hi! We are studying Drools 5.0 in order to use..
> But a curious problem has happened, while executeing an example in documentation.
> It is 3.1.3. Defining Processes Using the Process API in drools-5.0-docs\drools-flow\html_single\index.html.
> Actually, 3.1.3.1. Example 1 is working normally, but 3.1.3.2. Example 2 and 3.1.3.3. Example 3 occur error.
> I 'll tell you what we grasp the reason for error, so far.
> When it's working normal, <ActionNode> exists.
> The other way, when it is not working normal, <ActionNode> doesn't exist.
> For example, in case of 3.1.3.2. Example 2
> RuleFlowProcessFactory factory =
>     RuleFlowProcessFactory.createProcess("org.drools.HelloWorldJoinSplit");
> factory
>     // Header
>     .name("HelloWorldJoinSplit")
>     .version("1.0")
>     .packageName("org.drools")
>     // Nodes
>     .startNode(1).name("Start").done()
>     .splitNode(2).name("Split").type(Split.TYPE_AND).done()
>     .actionNode(3).name("Action 1")
>         .action("mvel", "System.out.println(\"Inside Action 1\")").done()                <       -here, NullPointerException occurs.
>     .actionNode(4).name("Action 2")
>         .action("mvel", "System.out.println(\"Inside Action 2\")").done()
>     .joinNode(5).type(Join.TYPE_AND).done()
>     .endNode(6).name("End").done()
>     // Connections
>     .connection(1, 2)
>     .connection(2, 3)
>     .connection(2, 4)
>     .connection(3, 5)
>     .connection(4, 5)
>     .connection(5, 6);
> RuleFlowProcess process = factory.validate().getProcess();
> Please, let me know entire source I can execute this example well.
> Thank you for your consideration.
> I am waiting for you answer.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 11:30:29 2009
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 30 Jul 2009 11:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2099) Example source.
In-Reply-To: <25948784.1243417258146.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <714321818.1248967829184.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478270#action_12478270 ] 

Kris Verlaenen commented on JBRULES-2099:
-----------------------------------------

When executing the code fragment you have provided, I do not see any NullPointerException.
Do you have a sample Java file that can be used to reproduce this?

> Example source.
> ---------------
>
>                 Key: JBRULES-2099
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2099
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP,eclipse
>            Reporter: gitae yang
>            Assignee: Kris Verlaenen
>             Fix For: 5.0.1.FINAL
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Hi! We are studying Drools 5.0 in order to use..
> But a curious problem has happened, while executeing an example in documentation.
> It is 3.1.3. Defining Processes Using the Process API in drools-5.0-docs\drools-flow\html_single\index.html.
> Actually, 3.1.3.1. Example 1 is working normally, but 3.1.3.2. Example 2 and 3.1.3.3. Example 3 occur error.
> I 'll tell you what we grasp the reason for error, so far.
> When it's working normal, <ActionNode> exists.
> The other way, when it is not working normal, <ActionNode> doesn't exist.
> For example, in case of 3.1.3.2. Example 2
> RuleFlowProcessFactory factory =
>     RuleFlowProcessFactory.createProcess("org.drools.HelloWorldJoinSplit");
> factory
>     // Header
>     .name("HelloWorldJoinSplit")
>     .version("1.0")
>     .packageName("org.drools")
>     // Nodes
>     .startNode(1).name("Start").done()
>     .splitNode(2).name("Split").type(Split.TYPE_AND).done()
>     .actionNode(3).name("Action 1")
>         .action("mvel", "System.out.println(\"Inside Action 1\")").done()                <       -here, NullPointerException occurs.
>     .actionNode(4).name("Action 2")
>         .action("mvel", "System.out.println(\"Inside Action 2\")").done()
>     .joinNode(5).type(Join.TYPE_AND).done()
>     .endNode(6).name("End").done()
>     // Connections
>     .connection(1, 2)
>     .connection(2, 3)
>     .connection(2, 4)
>     .connection(3, 5)
>     .connection(4, 5)
>     .connection(5, 6);
> RuleFlowProcess process = factory.validate().getProcess();
> Please, let me know entire source I can execute this example well.
> Thank you for your consideration.
> I am waiting for you answer.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 12:09:40 2009
From: jira-events at lists.jboss.org (Marek Posolda (JIRA))
Date: Thu, 30 Jul 2009 12:09:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2438) Partial refresh
 does not work with HTTPS
Message-ID: <173244925.1248970180853.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Partial refresh does not work with HTTPS
----------------------------------------

                 Key: JBPORTAL-2438
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2438
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.7.2 Final
         Environment: JBoss Portal from 2.7 branch, 
JBoss AS 4.2.3.GA
JDK 1.5 from Sun
            Reporter: Marek Posolda
             Fix For: 2.7.3 Final
         Attachments: server.xml

It seems that partial refresh does not work when trying to access JBoss Portal through HTTPS. The whole page is reloaded during each request on Partial Request Page.
SSL is configured with self-signed certificate (CN = localhost). server.xml is in attachement for entireness but it seems that problem is not in SSL configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 12:09:40 2009
From: jira-events at lists.jboss.org (Marek Posolda (JIRA))
Date: Thu, 30 Jul 2009 12:09:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-2438) Partial refresh
 does not work with HTTPS
In-Reply-To: <173244925.1248970180853.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <96509436.1248970180949.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBPORTAL-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Posolda updated JBPORTAL-2438:
------------------------------------

    Attachment: server.xml


> Partial refresh does not work with HTTPS
> ----------------------------------------
>
>                 Key: JBPORTAL-2438
>                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2438
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.7.2 Final
>         Environment: JBoss Portal from 2.7 branch, 
> JBoss AS 4.2.3.GA
> JDK 1.5 from Sun
>            Reporter: Marek Posolda
>             Fix For: 2.7.3 Final
>
>         Attachments: server.xml
>
>
> It seems that partial refresh does not work when trying to access JBoss Portal through HTTPS. The whole page is reloaded during each request on Partial Request Page.
> SSL is configured with self-signed certificate (CN = localhost). server.xml is in attachement for entireness but it seems that problem is not in SSL configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 12:34:29 2009
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Thu, 30 Jul 2009 12:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2221) duplicate
 function in different .drl files of same package silently overridden
Message-ID: <122753373.1248971669312.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

duplicate function in different .drl files of same package silently overridden
------------------------------------------------------------------------------

                 Key: JBRULES-2221
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2221
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler (expert)
    Affects Versions: 5.0.1.FINAL
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor


Given package p and .drl files a.drl and b.drl, both in this package.

If a.drl contains a function foo and b.drl a function foo, then b's function will silently supercede a's function, or vice versa. There is no indication of an error in the return value of kBuilder.getErrors().




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 12:41:29 2009
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Thu, 30 Jul 2009 12:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2222) Rule silently
 discarded if RHS calls an undefined DRL function
Message-ID: <263509633.1248972089469.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Rule silently discarded if RHS calls an undefined DRL function
--------------------------------------------------------------

                 Key: JBRULES-2222
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2222
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 5.0.1.FINAL
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor


If a function bar is called on a RHS of a rule in the same .drl file without being defined in the same .drl file, the .drl is compiled without kBuilder.getErrors() returning an error, and the rule is silently discarded (not firing, although it should). - Note that this error occurred when there was a function bar defined in another .drl file of the same package. 

Eclipse does indicate an error.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 12:41:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 30 Jul 2009 12:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-101) Add a stop() method
 to alias shutdown()
Message-ID: <1782760986.1248972089606.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add a stop() method to alias shutdown()
---------------------------------------

                 Key: JBBOOT-101
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-101
             Project: JBoss Bootstrap
          Issue Type: Feature Request
          Components: impl-base, spi
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger


Some users may be expecting server.stop(), so give it to them

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 12:47:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 30 Jul 2009 12:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-101) Add a stop()
 method to alias shutdown()
In-Reply-To: <1782760986.1248972089606.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <992657703.1248972449951.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-101.
----------------------------------------

    Fix Version/s: impl-base-2.0.0-alpha-4
                   spi-2.0.0-alpha-3
       Resolution: Done


> Add a stop() method to alias shutdown()
> ---------------------------------------
>
>                 Key: JBBOOT-101
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-101
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-base, spi
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: impl-base-2.0.0-alpha-4, spi-2.0.0-alpha-3
>
>
> Some users may be expecting server.stop(), so give it to them

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 12:47:30 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Thu, 30 Jul 2009 12:47:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6833) warnings from
 AbstractManagedObjectPopulator printed when ManagementView.load() is called
In-Reply-To: <6769558.1240600726809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <365633227.1248972450107.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478278#action_12478278 ] 

Ian Springer commented on JBAS-6833:
------------------------------------

>From Scott:

This is an artifact of attempting to get the jndi name before there is a value. We need to simply drop the logging level in the jboss-managed project.


> warnings from AbstractManagedObjectPopulator printed when ManagementView.load() is called
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-6833
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6833
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Ian Springer
>            Assignee: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>
> When I call ManagementView.load() , I see the following warnings in the log. They don't seem to cause any harm, but it would be good to fix whatever the underlying cause is, so they don't freak out users and waste space in the log.
> 14:10:03,459 WARN  [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 14:10:04,318 WARN  [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 14:10:04,334 WARN  [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
> 14:10:04,662 WARN  [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 12:58:29 2009
From: jira-events at lists.jboss.org (Bill Culp (JIRA))
Date: Thu, 30 Jul 2009 12:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-7137) MDBs dont register
 local-jndi-name when provided in jboss.xml
In-Reply-To: <1347556772.1248932189281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <738616551.1248973109205.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bill Culp reopened JBAS-7137:
-----------------------------



So the assertion being m,ade is that <local-jndi-name> which is in the jboss xsd does not exist, and has never worked.

This is incorrect, it does it exist and it used to work.  Please explain the deprectation process of the defined element

<local-jndi-name> under <message-driven> before rejecting a ticket outright.

> MDBs dont register local-jndi-name when provided in jboss.xml
> -------------------------------------------------------------
>
>                 Key: JBAS-7137
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7137
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: WIndows, Java 1.6 huge fat fast machine with thousands of terabytes
>            Reporter: Bill Culp
>            Assignee: Carlo de Wolf
>
> MDBs do not register a JNDI name at all even when local-jndi-name is specified in the jboss.xml and can only be looked up using jboss.j2ee:jar=foo, name=fooname, service=EJB3.
> Also start stop destroy create methods as provided for EJB beans in JMX are not provided.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 13:56:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 13:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-139) Bean Validation:
 TraversableResolver
Message-ID: <734460311.1248976589210.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Bean Validation: TraversableResolver
------------------------------------

                 Key: JBJCA-139
                 URL: https://jira.jboss.org/jira/browse/JBJCA-139
             Project: JBoss JCA
          Issue Type: Task
          Components: Standalone
            Reporter: Jesper Pedersen
            Assignee: Jeff Zhang
             Fix For: 1.0.0.Alpha3


Implement a JCATraversableResolver class that implements the TraversableResolver interface.

Both methods in the interface must return true.

Configure the ValidatorFactory to use this implementation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 14:22:29 2009
From: jira-events at lists.jboss.org (Brian Ko (JIRA))
Date: Thu, 30 Jul 2009 14:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-2439) Anonymous
 "admin" permission on a cms node prevent access from everyone except super
 user
Message-ID: <1200069976.1248978149206.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Anonymous "admin" permission on a cms node prevent access from everyone except super user
-----------------------------------------------------------------------------------------

                 Key: JBPORTAL-2439
                 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2439
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal CMS
    Affects Versions: 2.7.2 Final
         Environment: Windows XP, mySQL 5
            Reporter: Brian Ko
            Assignee: Sohil Shah


Anonymous "admin" permission on a cms node prevent access from everyone except super user

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 14:53:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 30 Jul 2009 14:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-102) Create distinction
 between SPI and API
Message-ID: <223180563.1248980009144.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Create distinction between SPI and API
--------------------------------------

                 Key: JBBOOT-102
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-102
             Project: JBoss Bootstrap
          Issue Type: Feature Request
          Components: api, api-as, api-mc, impl-as, impl-base, impl-mc, spi, spi-as, spi-mc
    Affects Versions: impl-as-2.0.0-alpha-3, impl-as-2.0.0-alpha-2, spi-as-2.0.0-alpha-3, spi-as-2.0.0-alpha-2 , spi-2.0.0-alpha-2 , impl-mc-2.0.0-alpha-2, impl-base-2.0.0-alpha-3, impl-base-2.0.0-alpha-2
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger


The client view of a server or config should not be leaking out internals required by the implementation itself.  Separate out the SPI to extend from an API, where the API is the client-only view.  The SPI may still be used by consuming projects like AS by casting the runtime type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 14:56:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 30 Jul 2009 14:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-103) Remove all
 IDE-specific metadata files
Message-ID: <831182085.1248980189267.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Remove all IDE-specific metadata files
--------------------------------------

                 Key: JBBOOT-103
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-103
             Project: JBoss Bootstrap
          Issue Type: Task
          Components: api, api-as, api-mc, build, impl-as, impl-base, impl-mc, legacy, main, spi, spi-as, spi-mc, spi-test
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: api-2.0.0-alpha-1, api-mc-2.0.0-alpha-1, impl-base-2.0.0-alpha-4, spi-2.0.0-alpha-3, spi-mc-2.0.0-alpha-2, api-as-2.0.0-alpha-1, spi-as-2.0.0-alpha-4, impl-as-2.0.0-alpha-4


I'm done with keeping IDE-specific stuff in SVN.  Remove 'em all, add svn:ignore for these, and let developers manage their own environments.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 14:58:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 30 Jul 2009 14:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-102) Create distinction
 between SPI and API
In-Reply-To: <223180563.1248980009144.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <825922336.1248980309149.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger updated JBBOOT-102:
---------------------------------------

        Fix Version/s: api-2.0.0-alpha-1
                       api-mc-2.0.0-alpha-1
                       impl-base-2.0.0-alpha-4
                       spi-2.0.0-alpha-3
                       spi-mc-2.0.0-alpha-2
                       api-as-2.0.0-alpha-1
                       spi-as-2.0.0-alpha-4
                       impl-as-2.0.0-alpha-4
    Affects Version/s:     (was: impl-as-2.0.0-alpha-2)
                           (was: spi-as-2.0.0-alpha-2 )
                           (was: spi-2.0.0-alpha-2 )
                           (was: impl-base-2.0.0-alpha-2)
                           (was: impl-base-2.0.0-alpha-3)
                           (was: spi-as-2.0.0-alpha-3)
                           (was: impl-mc-2.0.0-alpha-2)
                           (was: impl-as-2.0.0-alpha-3)


> Create distinction between SPI and API
> --------------------------------------
>
>                 Key: JBBOOT-102
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-102
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: api, api-as, api-mc, impl-as, impl-base, impl-mc, spi, spi-as, spi-mc
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: api-2.0.0-alpha-1, api-mc-2.0.0-alpha-1, impl-base-2.0.0-alpha-4, spi-2.0.0-alpha-3, spi-mc-2.0.0-alpha-2, api-as-2.0.0-alpha-1, spi-as-2.0.0-alpha-4, impl-as-2.0.0-alpha-4
>
>
> The client view of a server or config should not be leaking out internals required by the implementation itself.  Separate out the SPI to extend from an API, where the API is the client-only view.  The SPI may still be used by consuming projects like AS by casting the runtime type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 15:03:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 30 Jul 2009 15:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-104)
 JBossASBasedServerProvider.getMetadata() should return an immutable view
Message-ID: <1230586940.1248980609118.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBossASBasedServerProvider.getMetadata() should return an immutable view
------------------------------------------------------------------------

                 Key: JBBOOT-104
                 URL: https://jira.jboss.org/jira/browse/JBBOOT-104
             Project: JBoss Bootstrap
          Issue Type: Task
          Components: impl-as
            Reporter: Andrew Lee Rubinger
            Assignee: Andrew Lee Rubinger
             Fix For: impl-as-2.0.0-alpha-4


Get the nod from Scott/Emanuel on the linked forum Thread first to ensure that ProfileService isn't adding anything into the Map, but let's assume this constitutes leaking mutable state from the server to clients, and that's a no-no.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 15:40:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Thu, 30 Jul 2009 15:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCL-109) Infinite loop when a
 legit LinkageError occurs
In-Reply-To: <157425770.1247195069114.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1795685449.1248982829238.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBCL-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene updated JBCL-109:
---------------------------------

    Fix Version/s: JBossCL.2.0.6.SP1


> Infinite loop when a legit LinkageError occurs
> ----------------------------------------------
>
>                 Key: JBCL-109
>                 URL: https://jira.jboss.org/jira/browse/JBCL-109
>             Project: JBoss ClassLoader
>          Issue Type: Bug
>          Components: ClassLoader
>            Reporter: Jason T. Greene
>            Assignee: Jason T. Greene
>            Priority: Blocker
>             Fix For: JBossCL.2.0.6.SP1, JBossCL.2.0.7.GA
>
>
> To fix an old JVM issue, linkage errors are treated like a ClassCircularityError. The problem is due to the following type-o, if a legitimate linkage error occurs (like in JBAS-6327), an infinite loop results. 
> synchronized int incrementNumCCE()
>  {
>      return numCCE;;
>   }
> This appears to have already been fixed in trunk. It just needs to be included in a CL update on 2.0.7 ASAP

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 15:55:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 15:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6918) "trackByTxn"
 always gets displayed as "false" in the output of the "listStatistics"
 operation for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1955326651.1248983729576.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478309#action_12478309 ] 

Jesper Pedersen commented on JBAS-6918:
---------------------------------------

>From the docs:

# <track-connection-by-tx> - whether the connection should be "locked" to the transaction, returning it to the pool at the end of the transaction; in pre-JBoss-5.x releases the default value for Local connection factories is true and false for XA; since JBoss-5.x the default value is true for both Local and XA and the element is deprecated.
# <interleaving/> - enables interleaving for XA connection factories (added in JBoss-5.x)

The element is deprecated.

Let me know if I should remove it from the template.

> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Jesper Pedersen
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 15:55:29 2009
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 30 Jul 2009 15:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-6918) "trackByTxn" always
 gets displayed as "false" in the output of the "listStatistics" operation
 for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <286974471.1248983729734.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBAS-6918:
----------------------------------

    Assignee: Ian Springer  (was: Jesper Pedersen)


> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Ian Springer
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 16:48:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 30 Jul 2009 16:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-102) Create distinction
 between SPI and API
In-Reply-To: <223180563.1248980009144.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1981761517.1248986909152.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-102.
----------------------------------------

    Resolution: Done


> Create distinction between SPI and API
> --------------------------------------
>
>                 Key: JBBOOT-102
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-102
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: api, api-as, api-mc, impl-as, impl-base, impl-mc, spi, spi-as, spi-mc
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: api-2.0.0-alpha-1, api-mc-2.0.0-alpha-1, impl-base-2.0.0-alpha-4, spi-2.0.0-alpha-3, spi-mc-2.0.0-alpha-2, api-as-2.0.0-alpha-1, spi-as-2.0.0-alpha-4, impl-as-2.0.0-alpha-4
>
>
> The client view of a server or config should not be leaking out internals required by the implementation itself.  Separate out the SPI to extend from an API, where the API is the client-only view.  The SPI may still be used by consuming projects like AS by casting the runtime type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 17:00:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Thu, 30 Jul 2009 17:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-103) Remove all
 IDE-specific metadata files
In-Reply-To: <831182085.1248980189267.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1921557446.1248987629284.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-103.
----------------------------------------

    Resolution: Done


> Remove all IDE-specific metadata files
> --------------------------------------
>
>                 Key: JBBOOT-103
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-103
>             Project: JBoss Bootstrap
>          Issue Type: Task
>          Components: api, api-as, api-mc, build, impl-as, impl-base, impl-mc, legacy, main, spi, spi-as, spi-mc, spi-test
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: api-2.0.0-alpha-1, api-mc-2.0.0-alpha-1, impl-base-2.0.0-alpha-4, spi-2.0.0-alpha-3, spi-mc-2.0.0-alpha-2, api-as-2.0.0-alpha-1, spi-as-2.0.0-alpha-4, impl-as-2.0.0-alpha-4
>
>
> I'm done with keeping IDE-specific stuff in SVN.  Remove 'em all, add svn:ignore for these, and let developers manage their own environments.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 17:16:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Thu, 30 Jul 2009 17:16:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6918) "trackByTxn"
 always gets displayed as "false" in the output of the "listStatistics"
 operation for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1181110328.1248988589403.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478320#action_12478320 ] 

Ian Springer commented on JBAS-6918:
------------------------------------

Can you remove the trackByTxn element from the map that is returned by the listStatistics managed operation? It appears the value isn't accurate, since it is always false, even when the track-connection-by-tx managed property is set to true. I think it will only confuse users.


> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Ian Springer
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 17:18:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Thu, 30 Jul 2009 17:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6918) "trackByTxn" always
 gets displayed as "false" in the output of the "listStatistics" operation
 for Connection Factories and Datasources
In-Reply-To: <32049757.1242308746880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1876645012.1248988709262.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer reassigned JBAS-6918:
----------------------------------

    Assignee: Jesper Pedersen  (was: Ian Springer)


> "trackByTxn" always gets displayed as "false" in the output of the "listStatistics" operation for Connection Factories and Datasources
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-6918
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6918
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>         Environment: JBoss AS Branch_5_x r88814, embjopr r413 
>            Reporter: Farah Juma
>            Assignee: Jesper Pedersen
>            Priority: Minor
>             Fix For: JBossAS-5.2.0.Beta1
>
>         Attachments: ListStatistics.png
>
>
> Steps to reproduce:
> Create a Tx Connection Factory with "track-connection-by-tx" set to "true". Then, invoke the "listStatistics" operation using the Embedded Console. The value of "trackByTxn" gets displayed as "false" instead of "true", as seen in the attached screenshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 17:24:29 2009
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Thu, 30 Jul 2009 17:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7139) JmsXAResource not
 calculating isSameRM correctly
Message-ID: <1396028309.1248989069183.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JmsXAResource not calculating isSameRM correctly
------------------------------------------------

                 Key: JBAS-7139
                 URL: https://jira.jboss.org/jira/browse/JBAS-7139
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA service
    Affects Versions: JBossAS-5.1.0.GA, JBossAS-4.2.3.GA
            Reporter: Justin Bertram
            Assignee: Justin Bertram
             Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1


JmsXAResource.isSameRM will never return true if a JmsXAResource is passed to it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 17:35:29 2009
From: jira-events at lists.jboss.org (Jimmy Wilson (JIRA))
Date: Thu, 30 Jul 2009 17:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7140) HA-Singleton
	Injection
Message-ID: <1327201134.1248989729459.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

HA-Singleton Injection
----------------------

                 Key: JBAS-7140
                 URL: https://jira.jboss.org/jira/browse/JBAS-7140
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Clustering, EJB3
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Jimmy Wilson
            Assignee: Brian Stansberry


This is just a feature request to be able to inject EJBs and @Service beans such that if they are deployed via HA-Singleton, injection will work as expected via a transparent, delegating proxy on nodes that aren't collocated with the bean in question.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Jul 30 17:37:29 2009
From: jira-events at lists.jboss.org (David McCullars (JIRA))
Date: Thu, 30 Jul 2009 17:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6549) Investigate
 increased memory requirements and deployment time
In-Reply-To: <5128231.1235670884495.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1472561576.1248989849774.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478325#action_12478325 ] 

David McCullars commented on JBAS-6549:
---------------------------------------

We also are suffering from the memory problems in AS5.0.1, so much so we've switched to IBM's JRE (which seems to help slightly with OOME's).  Even still we have OOME's at least once a day in our production environment.  Has anyone tried AS5.1.0 to see if it's better?

> Investigate increased memory requirements and deployment time
> -------------------------------------------------------------
>
>                 Key: JBAS-6549
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6549
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.0.GA, JBossAS-5.0.1.GA
>            Reporter: Dimitris Andreadis
>            Assignee: Ales Justin
>         Attachments: AS 5_x profiler snapshot.zip
>
>
> A user reported x2 increase in deployment time and x4 increase in memory usage when moving an application from JBoss 4.2 -> 5.x.
> We need to investigate how to improve both the memory usage and the deployment time.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 00:43:29 2009
From: jira-events at lists.jboss.org (Andrew Lee Rubinger (JIRA))
Date: Fri, 31 Jul 2009 00:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-104)
 JBossASBasedServerProvider.getMetadata() should return an immutable view
In-Reply-To: <1230586940.1248980609118.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <188377293.1249015409648.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBOOT-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lee Rubinger resolved JBBOOT-104.
----------------------------------------

    Resolution: Done


> JBossASBasedServerProvider.getMetadata() should return an immutable view
> ------------------------------------------------------------------------
>
>                 Key: JBBOOT-104
>                 URL: https://jira.jboss.org/jira/browse/JBBOOT-104
>             Project: JBoss Bootstrap
>          Issue Type: Task
>          Components: impl-as
>            Reporter: Andrew Lee Rubinger
>            Assignee: Andrew Lee Rubinger
>             Fix For: impl-as-2.0.0-alpha-4
>
>
> Get the nod from Scott/Emanuel on the linked forum Thread first to ensure that ProfileService isn't adding anything into the Map, but let's assume this constitutes leaking mutable state from the server to clients, and that's a no-no.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 02:08:29 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Fri, 31 Jul 2009 02:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7130) Stack trace when
 starting up "all" configuration
In-Reply-To: <1446554410.1248826962724.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1603110312.1249020509482.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478353#action_12478353 ] 

Richard Opalka commented on JBAS-7130:
--------------------------------------

How to workaround this problem using default configuration Stan?

> Stack trace when starting up "all" configuration
> ------------------------------------------------
>
>                 Key: JBAS-7130
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7130
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF, Web (Tomcat) service
>            Reporter: David Lloyd
>            Assignee: Stan Silvert
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> I get the following stack trace when starting up in the "all" configuration:
> 19:19:07,154 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
> 19:19:07,187 WARNING [config] Unable to process deployment descriptor for context '/invoker': java.lang.IllegalArgumentException: InputStream cannot be null
> 	at javax.xml.parsers.SAXParser.parse(SAXParser.java:194)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.scanForFacesServlet(ConfigureListener.java:752)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.<init>(ConfigureListener.java:712)
> 	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:165)
> 	at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:60)
> 	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
> 	at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:462)
> 	at org.jboss.web.deployers.WebModule.startModule(WebModule.java:116)
> 	at org.jboss.web.deployers.WebModule.start(WebModule.java:95)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:207)
> 	at $Proxy38.start(Unknown Source)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:653)
> 	at org.jboss.system.ServiceController.register(ServiceController.java:356)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerRegistrationLifecycleCallback.install(ServiceControllerRegistrationLifecycleCallback.java:104)
> 	at sun.reflect.GeneratedMethodAccessor239.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 02:10:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Jul 2009 02:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1018)
 TP.sendToSingleMember NullPointerException
In-Reply-To: <847418881.1248957389599.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <457400447.1249020629153.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478354#action_12478354 ] 

Bela Ban commented on JGRP-1018:
--------------------------------

cvs -d:pserver:anonymous at javagroups.cvs.sourceforge.net:/cvsroot/javagroups login

cvs -z3 -d:pserver:anonymous at javagroups.cvs.sourceforge.net:/cvsroot/javagroups co -P JGroups

> TP.sendToSingleMember NullPointerException
> ------------------------------------------
>
>                 Key: JGRP-1018
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1018
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.8
>         Environment: Ubuntu Linux 9.04 64-bit
>            Reporter: Bulat Nigmatullin
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> 2009.07.30 16:28:47 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 2a1f5231-474b-aa1c-976d-70f5b32265af (108 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:76)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1436)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1382)
>         at org.jgroups.protocols.pbcast.NAKACK.stable(NAKACK.java:1354)
>         at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:581)
>         at org.jgroups.protocols.UNICAST.down(UNICAST.java:408)
>         at org.jgroups.protocols.pbcast.STABLE.handleStabilityMessage(STABLE.java:622)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:247)
>         at org.jgroups.protocols.UNICAST.up(UNICAST.java:297)
>         at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:823)
>         at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:686)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:271)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> 2009.07.30 16:28:58 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 38d9e5b6-4d65-20b4-7b41-7c6658e928d6 (172 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 02:29:51 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Fri, 31 Jul 2009 02:29:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1695)
 JMSServerControl.createQueue() fails when there are any paged messages for
 the Queue
Message-ID: <1851974409.1249021791965.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JMSServerControl.createQueue() fails when there are any paged messages for the Queue
------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1695
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1695
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0.beta4
         Environment: Windows Vista 32 bit 2GB RAM
            Reporter: Bijith Kumar
            Assignee: Tim Fox


Hi,
I am using JMSServerControl.createQueue() to create queues on the fly (programatically) as discussed in http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157444. This works fine and the API creates the Queue or just binds the queue to JNDI if queue already exists. However, this fails as soon as there are any messages paged in the Queue. i.e. If I am trying to use this API for a Queue which already exists and has some messages paged, subsequent calls to this API fails with following Exception. Test file is attached.

[code]java.lang.Exception: did not receive reply for message org.jboss.messaging.core.client.impl.ClientMessageImpl at 18e613d
	at org.jboss.messaging.core.management.impl.ReplicationOperationInvokerImpl.invoke(ReplicationOperationInvokerImpl.java:115)
	at org.jboss.messaging.core.management.jmx.impl.ReplicationAwareStandardMBeanWrapper.replicationAwareInvoke(ReplicationAwareStandardMBeanWrapper.java:75)
	at org.jboss.messaging.jms.server.management.jmx.impl.ReplicationAwareJMSServerControlWrapper.createQueue(ReplicationAwareJMSServerControlWrapper.java:499)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at com.sun.jmx.mbeanserver.StandardMetaDataImpl.invoke(StandardMetaDataImpl.java:414)
	at javax.management.StandardMBean.invoke(StandardMBean.java:323)
	at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
	at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1410)
	at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81)
	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1247)
	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1343)
	at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:784)
	at sun.reflect.GeneratedMethodAccessor27.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)[/code]


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 02:40:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 31 Jul 2009 02:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6314) Problems using EJB
 + Quartz + Seam
In-Reply-To: <29883538.1229034156614.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1908384151.1249022429348.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478357#action_12478357 ] 

jaikiran pai commented on JBAS-6314:
------------------------------------

This has been identified as a EJB3 issue and will be tracked/fixed  through EJBTHREE-1876. Marking this as an duplicate.


> Problems using EJB + Quartz + Seam
> ----------------------------------
>
>                 Key: JBAS-6314
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6314
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows Vista
>            Reporter: Diego Coronel
>            Assignee: Andrew Lee Rubinger
>   Original Estimate: 0 minutes
>  Remaining Estimate: 0 minutes
>
>  problems using quartz/seam with AS5, it works fine in jboss 4.2.2.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 02:42:29 2009
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 31 Jul 2009 02:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-6314) Problems using EJB
 + Quartz + Seam
In-Reply-To: <29883538.1229034156614.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2021657499.1249022549798.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBAS-6314.
--------------------------------

    Resolution: Duplicate Issue
      Assignee: jaikiran pai  (was: Andrew Lee Rubinger)


> Problems using EJB + Quartz + Seam
> ----------------------------------
>
>                 Key: JBAS-6314
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6314
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows Vista
>            Reporter: Diego Coronel
>            Assignee: jaikiran pai
>   Original Estimate: 0 minutes
>  Remaining Estimate: 0 minutes
>
>  problems using quartz/seam with AS5, it works fine in jboss 4.2.2.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 02:42:30 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Fri, 31 Jul 2009 02:42:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1695)
 JMSServerControl.createQueue() fails when there are any paged messages for
 the Queue
In-Reply-To: <1851974409.1249021791965.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <766573491.1249022550100.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bijith Kumar updated JBMESSAGING-1695:
--------------------------------------

    Attachment: Sender.java


Test

> JMSServerControl.createQueue() fails when there are any paged messages for the Queue
> ------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1695
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1695
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta4
>         Environment: Windows Vista 32 bit 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>         Attachments: Sender.java
>
>
> Hi,
> I am using JMSServerControl.createQueue() to create queues on the fly (programatically) as discussed in http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157444. This works fine and the API creates the Queue or just binds the queue to JNDI if queue already exists. However, this fails as soon as there are any messages paged in the Queue. i.e. If I am trying to use this API for a Queue which already exists and has some messages paged, subsequent calls to this API fails with following Exception. Test file is attached.
> [code]java.lang.Exception: did not receive reply for message org.jboss.messaging.core.client.impl.ClientMessageImpl at 18e613d
> 	at org.jboss.messaging.core.management.impl.ReplicationOperationInvokerImpl.invoke(ReplicationOperationInvokerImpl.java:115)
> 	at org.jboss.messaging.core.management.jmx.impl.ReplicationAwareStandardMBeanWrapper.replicationAwareInvoke(ReplicationAwareStandardMBeanWrapper.java:75)
> 	at org.jboss.messaging.jms.server.management.jmx.impl.ReplicationAwareJMSServerControlWrapper.createQueue(ReplicationAwareJMSServerControlWrapper.java:499)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at com.sun.jmx.mbeanserver.StandardMetaDataImpl.invoke(StandardMetaDataImpl.java:414)
> 	at javax.management.StandardMBean.invoke(StandardMBean.java:323)
> 	at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
> 	at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
> 	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1410)
> 	at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81)
> 	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1247)
> 	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1343)
> 	at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:784)
> 	at sun.reflect.GeneratedMethodAccessor27.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)[/code]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 02:49:41 2009
From: jira-events at lists.jboss.org (Bijith Kumar (JIRA))
Date: Fri, 31 Jul 2009 02:49:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1695)
 JMSServerControl.createQueue() fails when there are any paged messages for
 the Queue
In-Reply-To: <1851974409.1249021791965.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <241175632.1249022981350.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478359#action_12478359 ] 

Bijith Kumar commented on JBMESSAGING-1695:
-------------------------------------------

To reproduce the issue, just run the attached Java file 3 times (or more if your Queue memory is large). My Queue memory settings are as follows which can hold apx 23,745 messages


	          <global-page-size>10485760</global-page-size>
	          <paging-max-global-size-bytes>104857600</paging-max-global-size-bytes> 



> JMSServerControl.createQueue() fails when there are any paged messages for the Queue
> ------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1695
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1695
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta4
>         Environment: Windows Vista 32 bit 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Tim Fox
>         Attachments: Sender.java
>
>
> Hi,
> I am using JMSServerControl.createQueue() to create queues on the fly (programatically) as discussed in http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157444. This works fine and the API creates the Queue or just binds the queue to JNDI if queue already exists. However, this fails as soon as there are any messages paged in the Queue. i.e. If I am trying to use this API for a Queue which already exists and has some messages paged, subsequent calls to this API fails with following Exception. Test file is attached.
> [code]java.lang.Exception: did not receive reply for message org.jboss.messaging.core.client.impl.ClientMessageImpl at 18e613d
> 	at org.jboss.messaging.core.management.impl.ReplicationOperationInvokerImpl.invoke(ReplicationOperationInvokerImpl.java:115)
> 	at org.jboss.messaging.core.management.jmx.impl.ReplicationAwareStandardMBeanWrapper.replicationAwareInvoke(ReplicationAwareStandardMBeanWrapper.java:75)
> 	at org.jboss.messaging.jms.server.management.jmx.impl.ReplicationAwareJMSServerControlWrapper.createQueue(ReplicationAwareJMSServerControlWrapper.java:499)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at com.sun.jmx.mbeanserver.StandardMetaDataImpl.invoke(StandardMetaDataImpl.java:414)
> 	at javax.management.StandardMBean.invoke(StandardMBean.java:323)
> 	at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
> 	at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
> 	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1410)
> 	at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81)
> 	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1247)
> 	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1343)
> 	at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:784)
> 	at sun.reflect.GeneratedMethodAccessor27.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)[/code]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 03:57:29 2009
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 31 Jul 2009 03:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1695)
 JMSServerControl.createQueue() fails when there are any paged messages for
 the Queue
In-Reply-To: <1851974409.1249021791965.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1613602223.1249027049373.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned JBMESSAGING-1695:
----------------------------------------

    Assignee: Jeff Mesnil  (was: Tim Fox)


> JMSServerControl.createQueue() fails when there are any paged messages for the Queue
> ------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1695
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1695
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta4
>         Environment: Windows Vista 32 bit 2GB RAM
>            Reporter: Bijith Kumar
>            Assignee: Jeff Mesnil
>         Attachments: Sender.java
>
>
> Hi,
> I am using JMSServerControl.createQueue() to create queues on the fly (programatically) as discussed in http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157444. This works fine and the API creates the Queue or just binds the queue to JNDI if queue already exists. However, this fails as soon as there are any messages paged in the Queue. i.e. If I am trying to use this API for a Queue which already exists and has some messages paged, subsequent calls to this API fails with following Exception. Test file is attached.
> [code]java.lang.Exception: did not receive reply for message org.jboss.messaging.core.client.impl.ClientMessageImpl at 18e613d
> 	at org.jboss.messaging.core.management.impl.ReplicationOperationInvokerImpl.invoke(ReplicationOperationInvokerImpl.java:115)
> 	at org.jboss.messaging.core.management.jmx.impl.ReplicationAwareStandardMBeanWrapper.replicationAwareInvoke(ReplicationAwareStandardMBeanWrapper.java:75)
> 	at org.jboss.messaging.jms.server.management.jmx.impl.ReplicationAwareJMSServerControlWrapper.createQueue(ReplicationAwareJMSServerControlWrapper.java:499)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at com.sun.jmx.mbeanserver.StandardMetaDataImpl.invoke(StandardMetaDataImpl.java:414)
> 	at javax.management.StandardMBean.invoke(StandardMBean.java:323)
> 	at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
> 	at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
> 	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1410)
> 	at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81)
> 	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1247)
> 	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1343)
> 	at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:784)
> 	at sun.reflect.GeneratedMethodAccessor27.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)[/code]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 04:38:29 2009
From: jira-events at lists.jboss.org (Assen Todorov (JIRA))
Date: Fri, 31 Jul 2009 04:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2223)
 ArrayIndexOutOfBoundsException in AbstractRuleBase.getStatefulSessions()
Message-ID: <14379227.1249029509459.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

ArrayIndexOutOfBoundsException in AbstractRuleBase.getStatefulSessions()
------------------------------------------------------------------------

                 Key: JBRULES-2223
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2223
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 4.0.7
            Reporter: Assen Todorov
            Assignee: Mark Proctor


The following exception is thrown on a multithreaded application, based on Terracotta & JBoss Drools (4.0.7).

{code}
java.lang.ArrayIndexOutOfBoundsException: 0
        at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:152)
        at org.drools.common.AbstractRuleBase.getStatefulSessions(AbstractRuleBase.java:724)
        .......
{code}

The code :

{code}
   /**
    * Creates a new rule base if necesarry.
    * @param aRuleSet the rule set for the new rule base.
    * @throws RuleConversionException if the rule engine has a problem with rule set compilation and loading.
    */
   private void createRuleBase(final RuleSet aRuleSet) throws RuleConversionException
   {
      Check.notNull(aRuleSet, "aRuleSet");
      final String code = aRuleSet.getCode();
      Check.notNull(code, "aRuleSet.getCode()");
      Check.notEmpty(code, "aRuleSet.getCode()");

      final ECRC ecrc = new ECRC();
      ecrc.update(code);
      final long crc = ecrc.getValue();

      synchronized(ruleBaseCache)
      {
         ruleBase = ruleBaseCache.get(crc);
         if(ruleBase == null)
         {
            ruleBase = loadRuleBaseFromCode(code);
            ruleBaseCache.put(crc, ruleBase);
         }
         else {
            // rulebase already exist
            final StatefulSession[] sessions = ruleBase.getStatefulSessions();
            if(sessions.length > 0) {
               // old sessions (working memories exist)
               for(StatefulSession session: sessions) {
                  // clear the working memory
                  session.dispose();
               }
            }
         }
      }
   }
{code}

The class where this method is defined, is declared as _instrumented-classes_  in the Terracotta configuration.

Hope this helps !

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 04:40:29 2009
From: jira-events at lists.jboss.org (Assen Todorov (JIRA))
Date: Fri, 31 Jul 2009 04:40:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2223)
 ArrayIndexOutOfBoundsException in AbstractRuleBase.getStatefulSessions()
In-Reply-To: <14379227.1249029509459.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <185046907.1249029629194.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Assen Todorov updated JBRULES-2223:
-----------------------------------

    Description: 
The following exception is thrown on a clustered application, based on Terracotta & JBoss Drools (4.0.7).

{code}
java.lang.ArrayIndexOutOfBoundsException: 0
        at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:152)
        at org.drools.common.AbstractRuleBase.getStatefulSessions(AbstractRuleBase.java:724)
        .......
{code}

The code :

{code}
   /**
    * Creates a new rule base if necesarry.
    * @param aRuleSet the rule set for the new rule base.
    * @throws RuleConversionException if the rule engine has a problem with rule set compilation and loading.
    */
   private void createRuleBase(final RuleSet aRuleSet) throws RuleConversionException
   {
      Check.notNull(aRuleSet, "aRuleSet");
      final String code = aRuleSet.getCode();
      Check.notNull(code, "aRuleSet.getCode()");
      Check.notEmpty(code, "aRuleSet.getCode()");

      final ECRC ecrc = new ECRC();
      ecrc.update(code);
      final long crc = ecrc.getValue();

      synchronized(ruleBaseCache)
      {
         ruleBase = ruleBaseCache.get(crc);
         if(ruleBase == null)
         {
            ruleBase = loadRuleBaseFromCode(code);
            ruleBaseCache.put(crc, ruleBase);
         }
         else {
            // rulebase already exist
            final StatefulSession[] sessions = ruleBase.getStatefulSessions();
            if(sessions.length > 0) {
               // old sessions (working memories exist)
               for(StatefulSession session: sessions) {
                  // clear the working memory
                  session.dispose();
               }
            }
         }
      }
   }
{code}

The class where this method is defined, is declared as _instrumented-classes_  in the Terracotta configuration.

Hope this helps !

  was:
The following exception is thrown on a multithreaded application, based on Terracotta & JBoss Drools (4.0.7).

{code}
java.lang.ArrayIndexOutOfBoundsException: 0
        at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:152)
        at org.drools.common.AbstractRuleBase.getStatefulSessions(AbstractRuleBase.java:724)
        .......
{code}

The code :

{code}
   /**
    * Creates a new rule base if necesarry.
    * @param aRuleSet the rule set for the new rule base.
    * @throws RuleConversionException if the rule engine has a problem with rule set compilation and loading.
    */
   private void createRuleBase(final RuleSet aRuleSet) throws RuleConversionException
   {
      Check.notNull(aRuleSet, "aRuleSet");
      final String code = aRuleSet.getCode();
      Check.notNull(code, "aRuleSet.getCode()");
      Check.notEmpty(code, "aRuleSet.getCode()");

      final ECRC ecrc = new ECRC();
      ecrc.update(code);
      final long crc = ecrc.getValue();

      synchronized(ruleBaseCache)
      {
         ruleBase = ruleBaseCache.get(crc);
         if(ruleBase == null)
         {
            ruleBase = loadRuleBaseFromCode(code);
            ruleBaseCache.put(crc, ruleBase);
         }
         else {
            // rulebase already exist
            final StatefulSession[] sessions = ruleBase.getStatefulSessions();
            if(sessions.length > 0) {
               // old sessions (working memories exist)
               for(StatefulSession session: sessions) {
                  // clear the working memory
                  session.dispose();
               }
            }
         }
      }
   }
{code}

The class where this method is defined, is declared as _instrumented-classes_  in the Terracotta configuration.

Hope this helps !



> ArrayIndexOutOfBoundsException in AbstractRuleBase.getStatefulSessions()
> ------------------------------------------------------------------------
>
>                 Key: JBRULES-2223
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2223
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0.7
>            Reporter: Assen Todorov
>            Assignee: Mark Proctor
>
> The following exception is thrown on a clustered application, based on Terracotta & JBoss Drools (4.0.7).
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 0
>         at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:152)
>         at org.drools.common.AbstractRuleBase.getStatefulSessions(AbstractRuleBase.java:724)
>         .......
> {code}
> The code :
> {code}
>    /**
>     * Creates a new rule base if necesarry.
>     * @param aRuleSet the rule set for the new rule base.
>     * @throws RuleConversionException if the rule engine has a problem with rule set compilation and loading.
>     */
>    private void createRuleBase(final RuleSet aRuleSet) throws RuleConversionException
>    {
>       Check.notNull(aRuleSet, "aRuleSet");
>       final String code = aRuleSet.getCode();
>       Check.notNull(code, "aRuleSet.getCode()");
>       Check.notEmpty(code, "aRuleSet.getCode()");
>       final ECRC ecrc = new ECRC();
>       ecrc.update(code);
>       final long crc = ecrc.getValue();
>       synchronized(ruleBaseCache)
>       {
>          ruleBase = ruleBaseCache.get(crc);
>          if(ruleBase == null)
>          {
>             ruleBase = loadRuleBaseFromCode(code);
>             ruleBaseCache.put(crc, ruleBase);
>          }
>          else {
>             // rulebase already exist
>             final StatefulSession[] sessions = ruleBase.getStatefulSessions();
>             if(sessions.length > 0) {
>                // old sessions (working memories exist)
>                for(StatefulSession session: sessions) {
>                   // clear the working memory
>                   session.dispose();
>                }
>             }
>          }
>       }
>    }
> {code}
> The class where this method is defined, is declared as _instrumented-classes_  in the Terracotta configuration.
> Hope this helps !

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 04:43:29 2009
From: jira-events at lists.jboss.org (Tej jbpm (JIRA))
Date: Fri, 31 Jul 2009 04:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-368) Unable to delete
	process instance
Message-ID: <535972591.1249029809145.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Unable to delete process instance 
----------------------------------

                 Key: GPD-368
                 URL: https://jira.jboss.org/jira/browse/GPD-368
             Project: JBoss jBPM GPD
          Issue Type: Bug
          Components: jpdl
    Affects Versions: jBPM jPDL Designer 3.2
         Environment: Eclipse 3.4.2, JBPM JPDL 3.2.1
            Reporter: Tej jbpm
            Assignee: Koen Aers


Whenever I have a process state node in my process definition ..I am unable to delete the process definition.
This is the error message:
2009-07-31 09:34:13,009 [http-80-Processor25]  WARN (JDBCExceptionReporter.java:77) - SQL Error: 1451, SQLState: 23000

2009-07-31 09:34:13,010 [http-80-Processor25] ERROR (JDBCExceptionReporter.java:78) - Cannot delete or update a parent row: a foreign key constraint fails (`bapsr`.`jbpm_node`, CONSTRAINT `fk_procst_sbprcdef` FOREIGN KEY (`subprocessdefinition_`) REFERENCES `jbpm_processdefinition` (`id_`))

2009-07-31 09:34:13,010 [http-80-Processor25] ERROR (AbstractFlushingEventListener.java:301) - 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:253)

	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:235)

	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:144)

	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.jbpm.jsf.core.action.DeleteActionListener.handleAction(DeleteActionListener.java:50)

	at org.jbpm.jsf.core.impl.JbpmActionListenerWrapper.processAction(JbpmActionListenerWrapper.java:82)

	at javax.faces.event.ActionEvent.processListener(ActionEvent.java:77)

	at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:758)

	at javax.faces.component.UICommand.broadcast(UICommand.java:368)

	at org.ajax4jsf.component.AjaxViewRoot.processEvents(AjaxViewRoot.java:186)

	at org.ajax4jsf.component.AjaxViewRoot.broadcastEvents(AjaxViewRoot.java:164)

	at org.ajax4jsf.component.AjaxViewRoot.processApplication(AjaxViewRoot.java:352)

	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:97)

	at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)

	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)

	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)

	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)

	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)

	at com.njw.session.BASessionExpiryFilter.doFilter(BASessionExpiryFilter.java:43)

	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)

	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)

	at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)

	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)

	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.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.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)

	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)

	at java.lang.Thread.run(Thread.java:595)

Caused by: java.sql.BatchUpdateException: Cannot delete or update a parent row: a foreign key constraint fails (`bapsr`.`jbpm_node`, CONSTRAINT `fk_procst_sbprcdef` FOREIGN KEY (`subprocessdefinition_`) REFERENCES `jbpm_processdefinition` (`id_`))

	at com.mysql.jdbc.ServerPreparedStatement.executeBatch(ServerPreparedStatement.java:665)

	at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:48)

	at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:246)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 04:56:29 2009
From: jira-events at lists.jboss.org (Assen Todorov (JIRA))
Date: Fri, 31 Jul 2009 04:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2223)
 ArrayIndexOutOfBoundsException in AbstractRuleBase.getStatefulSessions()
In-Reply-To: <14379227.1249029509459.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1334691220.1249030589213.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Assen Todorov updated JBRULES-2223:
-----------------------------------

    Description: 
The following exception was thrown on a clustered application, based on Terracotta & JBoss Drools (4.0.7).

{code}
java.lang.ArrayIndexOutOfBoundsException: 0
        at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:152)
        at org.drools.common.AbstractRuleBase.getStatefulSessions(AbstractRuleBase.java:724)
        .......
{code}

The code :

{code}
   /**
    * Creates a new rule base if necesarry.
    * @param aRuleSet the rule set for the new rule base.
    * @throws RuleConversionException if the rule engine has a problem with rule set compilation and loading.
    */
   private void createRuleBase(final RuleSet aRuleSet) throws RuleConversionException
   {
      Check.notNull(aRuleSet, "aRuleSet");
      final String code = aRuleSet.getCode();
      Check.notNull(code, "aRuleSet.getCode()");
      Check.notEmpty(code, "aRuleSet.getCode()");

      final ECRC ecrc = new ECRC();
      ecrc.update(code);
      final long crc = ecrc.getValue();

      synchronized(ruleBaseCache)
      {
         ruleBase = ruleBaseCache.get(crc);
         if(ruleBase == null)
         {
            ruleBase = loadRuleBaseFromCode(code);
            ruleBaseCache.put(crc, ruleBase);
         }
         else {
            // rulebase already exist
            final StatefulSession[] sessions = ruleBase.getStatefulSessions();
            if(sessions.length > 0) {
               // old sessions (working memories exist)
               for(StatefulSession session: sessions) {
                  // clear the working memory
                  session.dispose();
               }
            }
         }
      }
   }
{code}

The class where this method is defined, is declared as _instrumented-classes_  in the Terracotta configuration.

Hope this helps !

  was:
The following exception is thrown on a clustered application, based on Terracotta & JBoss Drools (4.0.7).

{code}
java.lang.ArrayIndexOutOfBoundsException: 0
        at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:152)
        at org.drools.common.AbstractRuleBase.getStatefulSessions(AbstractRuleBase.java:724)
        .......
{code}

The code :

{code}
   /**
    * Creates a new rule base if necesarry.
    * @param aRuleSet the rule set for the new rule base.
    * @throws RuleConversionException if the rule engine has a problem with rule set compilation and loading.
    */
   private void createRuleBase(final RuleSet aRuleSet) throws RuleConversionException
   {
      Check.notNull(aRuleSet, "aRuleSet");
      final String code = aRuleSet.getCode();
      Check.notNull(code, "aRuleSet.getCode()");
      Check.notEmpty(code, "aRuleSet.getCode()");

      final ECRC ecrc = new ECRC();
      ecrc.update(code);
      final long crc = ecrc.getValue();

      synchronized(ruleBaseCache)
      {
         ruleBase = ruleBaseCache.get(crc);
         if(ruleBase == null)
         {
            ruleBase = loadRuleBaseFromCode(code);
            ruleBaseCache.put(crc, ruleBase);
         }
         else {
            // rulebase already exist
            final StatefulSession[] sessions = ruleBase.getStatefulSessions();
            if(sessions.length > 0) {
               // old sessions (working memories exist)
               for(StatefulSession session: sessions) {
                  // clear the working memory
                  session.dispose();
               }
            }
         }
      }
   }
{code}

The class where this method is defined, is declared as _instrumented-classes_  in the Terracotta configuration.

Hope this helps !



> ArrayIndexOutOfBoundsException in AbstractRuleBase.getStatefulSessions()
> ------------------------------------------------------------------------
>
>                 Key: JBRULES-2223
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2223
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0.7
>            Reporter: Assen Todorov
>            Assignee: Mark Proctor
>
> The following exception was thrown on a clustered application, based on Terracotta & JBoss Drools (4.0.7).
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 0
>         at org.drools.util.ObjectHashSet.toArray(ObjectHashSet.java:152)
>         at org.drools.common.AbstractRuleBase.getStatefulSessions(AbstractRuleBase.java:724)
>         .......
> {code}
> The code :
> {code}
>    /**
>     * Creates a new rule base if necesarry.
>     * @param aRuleSet the rule set for the new rule base.
>     * @throws RuleConversionException if the rule engine has a problem with rule set compilation and loading.
>     */
>    private void createRuleBase(final RuleSet aRuleSet) throws RuleConversionException
>    {
>       Check.notNull(aRuleSet, "aRuleSet");
>       final String code = aRuleSet.getCode();
>       Check.notNull(code, "aRuleSet.getCode()");
>       Check.notEmpty(code, "aRuleSet.getCode()");
>       final ECRC ecrc = new ECRC();
>       ecrc.update(code);
>       final long crc = ecrc.getValue();
>       synchronized(ruleBaseCache)
>       {
>          ruleBase = ruleBaseCache.get(crc);
>          if(ruleBase == null)
>          {
>             ruleBase = loadRuleBaseFromCode(code);
>             ruleBaseCache.put(crc, ruleBase);
>          }
>          else {
>             // rulebase already exist
>             final StatefulSession[] sessions = ruleBase.getStatefulSessions();
>             if(sessions.length > 0) {
>                // old sessions (working memories exist)
>                for(StatefulSession session: sessions) {
>                   // clear the working memory
>                   session.dispose();
>                }
>             }
>          }
>       }
>    }
> {code}
> The class where this method is defined, is declared as _instrumented-classes_  in the Terracotta configuration.
> Hope this helps !

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 04:56:29 2009
From: jira-events at lists.jboss.org (Bulat Nigmatullin (JIRA))
Date: Fri, 31 Jul 2009 04:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1018)
 TP.sendToSingleMember NullPointerException
In-Reply-To: <847418881.1248957389599.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <246212737.1249030589315.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478362#action_12478362 ] 

Bulat Nigmatullin commented on JGRP-1018:
-----------------------------------------

I've checked out jgroups. You say there shouldn't to be sendToSingleMember() method, but it is still there and produces the same error. May be you gave me wrong CVS URL?

> TP.sendToSingleMember NullPointerException
> ------------------------------------------
>
>                 Key: JGRP-1018
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1018
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.8
>         Environment: Ubuntu Linux 9.04 64-bit
>            Reporter: Bulat Nigmatullin
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> 2009.07.30 16:28:47 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 2a1f5231-474b-aa1c-976d-70f5b32265af (108 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:76)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1436)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1382)
>         at org.jgroups.protocols.pbcast.NAKACK.stable(NAKACK.java:1354)
>         at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:581)
>         at org.jgroups.protocols.UNICAST.down(UNICAST.java:408)
>         at org.jgroups.protocols.pbcast.STABLE.handleStabilityMessage(STABLE.java:622)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:247)
>         at org.jgroups.protocols.UNICAST.up(UNICAST.java:297)
>         at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:823)
>         at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:686)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:271)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> 2009.07.30 16:28:58 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 38d9e5b6-4d65-20b4-7b41-7c6658e928d6 (172 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 05:03:29 2009
From: jira-events at lists.jboss.org (Howard Gao (JIRA))
Date: Fri, 31 Jul 2009 05:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1680) Improving
 the startup of Messaging Post Office service
In-Reply-To: <443833333.1247032268842.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1051517036.1249031009240.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478364#action_12478364 ] 

Howard Gao commented on JBMESSAGING-1680:
-----------------------------------------


By kicking off another thread to start the data channel in GroupMember, we can save about 2 sec. See data:

 Total duration: 4040  [GroupMember]
 -----------------------------------------------
 [create-control-channel] : dur 15 ---> 0.37%
 [kickoff-data-thread] : dur 23 ---> 0.57%
 [connect-control-channel] : dur 2008 ---> 49.7%
 [waiting-data-channel] : dur 1994 ---> 49.36%
 -----------------------------------------------
 Total duration: 4120  [Messaging PostOffice]
 -----------------------------------------------
 [super-start] : dur 2 ---> 0.05%
 [office-init] : dur 0 ---> 0.0%
 [get-bindings-from-storage] : dur 24 ---> 0.58%
 [groupmember-start] : dur 4049 ---> 98.28%
 [cluster-init] : dur 37 ---> 0.9%
 [load-bindings] : dur 8 ---> 0.19%
 -----------------------------------------------


> Improving the startup of Messaging Post Office service
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1680
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1680
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Howard Gao
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>
> Investigating the possibility of starting the two JGroups channels concurrently so that the startup process will be faster.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 05:19:29 2009
From: jira-events at lists.jboss.org (Bulat Nigmatullin (JIRA))
Date: Fri, 31 Jul 2009 05:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1018)
 TP.sendToSingleMember NullPointerException
In-Reply-To: <847418881.1248957389599.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <458173589.1249031969560.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478365#action_12478365 ] 

Bulat Nigmatullin commented on JGRP-1018:
-----------------------------------------

May this problem be linked to 'could not flush the cluster for state retrieval' problem on other node joining to the cluster?

> TP.sendToSingleMember NullPointerException
> ------------------------------------------
>
>                 Key: JGRP-1018
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1018
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.8
>         Environment: Ubuntu Linux 9.04 64-bit
>            Reporter: Bulat Nigmatullin
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> 2009.07.30 16:28:47 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 2a1f5231-474b-aa1c-976d-70f5b32265af (108 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:76)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1436)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1382)
>         at org.jgroups.protocols.pbcast.NAKACK.stable(NAKACK.java:1354)
>         at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:581)
>         at org.jgroups.protocols.UNICAST.down(UNICAST.java:408)
>         at org.jgroups.protocols.pbcast.STABLE.handleStabilityMessage(STABLE.java:622)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:247)
>         at org.jgroups.protocols.UNICAST.up(UNICAST.java:297)
>         at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:823)
>         at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:686)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:271)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> 2009.07.30 16:28:58 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 38d9e5b6-4d65-20b4-7b41-7c6658e928d6 (172 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 05:27:29 2009
From: jira-events at lists.jboss.org (Koen Aers (JIRA))
Date: Fri, 31 Jul 2009 05:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (GPD-368) Unable to delete
	process instance
In-Reply-To: <535972591.1249029809145.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1979941882.1249032449305.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/GPD-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Koen Aers resolved GPD-368.
---------------------------

    Resolution: Rejected


This problem is not related to the graphical designer. Please use the JBPM project in JIRA if it is a problem related to the engine.

> Unable to delete process instance 
> ----------------------------------
>
>                 Key: GPD-368
>                 URL: https://jira.jboss.org/jira/browse/GPD-368
>             Project: JBoss jBPM GPD
>          Issue Type: Bug
>          Components: jpdl
>    Affects Versions: jBPM jPDL Designer 3.2
>         Environment: Eclipse 3.4.2, JBPM JPDL 3.2.1
>            Reporter: Tej jbpm
>            Assignee: Koen Aers
>
> Whenever I have a process state node in my process definition ..I am unable to delete the process definition.
> This is the error message:
> 2009-07-31 09:34:13,009 [http-80-Processor25]  WARN (JDBCExceptionReporter.java:77) - SQL Error: 1451, SQLState: 23000
> 2009-07-31 09:34:13,010 [http-80-Processor25] ERROR (JDBCExceptionReporter.java:78) - Cannot delete or update a parent row: a foreign key constraint fails (`bapsr`.`jbpm_node`, CONSTRAINT `fk_procst_sbprcdef` FOREIGN KEY (`subprocessdefinition_`) REFERENCES `jbpm_processdefinition` (`id_`))
> 2009-07-31 09:34:13,010 [http-80-Processor25] ERROR (AbstractFlushingEventListener.java:301) - 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:253)
> 	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:235)
> 	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:144)
> 	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.jbpm.jsf.core.action.DeleteActionListener.handleAction(DeleteActionListener.java:50)
> 	at org.jbpm.jsf.core.impl.JbpmActionListenerWrapper.processAction(JbpmActionListenerWrapper.java:82)
> 	at javax.faces.event.ActionEvent.processListener(ActionEvent.java:77)
> 	at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:758)
> 	at javax.faces.component.UICommand.broadcast(UICommand.java:368)
> 	at org.ajax4jsf.component.AjaxViewRoot.processEvents(AjaxViewRoot.java:186)
> 	at org.ajax4jsf.component.AjaxViewRoot.broadcastEvents(AjaxViewRoot.java:164)
> 	at org.ajax4jsf.component.AjaxViewRoot.processApplication(AjaxViewRoot.java:352)
> 	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:97)
> 	at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at com.njw.session.BASessionExpiryFilter.doFilter(BASessionExpiryFilter.java:43)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
> 	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
> 	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.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.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> 	at java.lang.Thread.run(Thread.java:595)
> Caused by: java.sql.BatchUpdateException: Cannot delete or update a parent row: a foreign key constraint fails (`bapsr`.`jbpm_node`, CONSTRAINT `fk_procst_sbprcdef` FOREIGN KEY (`subprocessdefinition_`) REFERENCES `jbpm_processdefinition` (`id_`))
> 	at com.mysql.jdbc.ServerPreparedStatement.executeBatch(ServerPreparedStatement.java:665)
> 	at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:48)
> 	at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:246)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 05:32:46 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Jul 2009 05:32:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1018)
 TP.sendToSingleMember NullPointerException
In-Reply-To: <847418881.1248957389599.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1503146293.1249032766049.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478367#action_12478367 ] 

Bela Ban commented on JGRP-1018:
--------------------------------

OK, I need the stack trace for CVS head, or else I cannot match the line numbers, please attach it to this case (lastest CVS)

> TP.sendToSingleMember NullPointerException
> ------------------------------------------
>
>                 Key: JGRP-1018
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1018
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.8
>         Environment: Ubuntu Linux 9.04 64-bit
>            Reporter: Bulat Nigmatullin
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> 2009.07.30 16:28:47 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 2a1f5231-474b-aa1c-976d-70f5b32265af (108 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:76)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1436)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1382)
>         at org.jgroups.protocols.pbcast.NAKACK.stable(NAKACK.java:1354)
>         at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:581)
>         at org.jgroups.protocols.UNICAST.down(UNICAST.java:408)
>         at org.jgroups.protocols.pbcast.STABLE.handleStabilityMessage(STABLE.java:622)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:247)
>         at org.jgroups.protocols.UNICAST.up(UNICAST.java:297)
>         at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:823)
>         at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:686)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:271)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> 2009.07.30 16:28:58 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 38d9e5b6-4d65-20b4-7b41-7c6658e928d6 (172 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 05:42:29 2009
From: jira-events at lists.jboss.org (Bulat Nigmatullin (JIRA))
Date: Fri, 31 Jul 2009 05:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1018)
 TP.sendToSingleMember NullPointerException
In-Reply-To: <847418881.1248957389599.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <427966290.1249033349498.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JGRP-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478369#action_12478369 ] 

Bulat Nigmatullin commented on JGRP-1018:
-----------------------------------------

2009.07.31 13:15:05 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 177de77e-d5af-e6db-d4f1-8b9b3cb4d8ff (172 bytes)
java.lang.NullPointerException
        at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1081)
        at org.jgroups.protocols.TP.doSend(TP.java:1069)
        at org.jgroups.protocols.TP.send(TP.java:1052)
        at org.jgroups.protocols.TP.down(TP.java:913)
        at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1912)
        at org.jgroups.protocols.Discovery.down(Discovery.java:406)
        at org.jgroups.protocols.TCPPING.down(TCPPING.java:148)
        at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
        at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
        at org.jgroups.protocols.FD.down(FD.java:300)
        at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
        at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
        at org.jgroups.protocols.FD.up(FD.java:265)
        at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
        at org.jgroups.stack.Protocol.up(Protocol.java:336)
        at org.jgroups.protocols.Discovery.up(Discovery.java:234)
        at org.jgroups.stack.Protocol.up(Protocol.java:336)
        at org.jgroups.protocols.TP.passMessageUp(TP.java:964)
        at org.jgroups.protocols.TP.access$100(TP.java:53)
        at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1478)
        at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1455)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)


> TP.sendToSingleMember NullPointerException
> ------------------------------------------
>
>                 Key: JGRP-1018
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1018
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.8
>         Environment: Ubuntu Linux 9.04 64-bit
>            Reporter: Bulat Nigmatullin
>            Assignee: Bela Ban
>             Fix For: 2.8
>
>
> 2009.07.30 16:28:47 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 2a1f5231-474b-aa1c-976d-70f5b32265af (108 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:76)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1436)
>         at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1382)
>         at org.jgroups.protocols.pbcast.NAKACK.stable(NAKACK.java:1354)
>         at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:581)
>         at org.jgroups.protocols.UNICAST.down(UNICAST.java:408)
>         at org.jgroups.protocols.pbcast.STABLE.handleStabilityMessage(STABLE.java:622)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:247)
>         at org.jgroups.protocols.UNICAST.up(UNICAST.java:297)
>         at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:823)
>         at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:686)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:271)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)
> 2009.07.30 16:28:58 [java.util.logging.Logger.log(Logger.java:472)] failed sending message to 38d9e5b6-4d65-20b4-7b41-7c6658e928d6 (172 bytes)
> java.lang.NullPointerException
>         at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1101)
>         at org.jgroups.protocols.TP.doSend(TP.java:1090)
>         at org.jgroups.protocols.TP.send(TP.java:1073)
>         at org.jgroups.protocols.TP.down(TP.java:934)
>         at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:1929)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:411)
>         at org.jgroups.protocols.TCPPING.down(TCPPING.java:139)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:163)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:334)
>         at org.jgroups.protocols.FD.down(FD.java:300)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:214)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:98)
>         at org.jgroups.protocols.FD.up(FD.java:265)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:199)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:234)
>         at org.jgroups.stack.Protocol.up(Protocol.java:336)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:985)
>         at org.jgroups.protocols.TP.access$100(TP.java:53)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1502)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1479)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 06:12:29 2009
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Fri, 31 Jul 2009 06:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-2224) multi-restriction
 pattern throws UnsupportedOpEx
Message-ID: <556477230.1249035149164.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

multi-restriction pattern throws UnsupportedOpEx
------------------------------------------------

                 Key: JBRULES-2224
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2224
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler (expert)
    Affects Versions: 5.0.1.FINAL
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor


rule "same"
when
    $m : ShGraphType( $x25No : x25No, $trans : trans )
      GoType( x25No == $x25No || == ($x25No % 2000), trans != $trans )  #!!!#
    $e : ShType( x25No == $x25No )
    $v : View( elemSet contains $m )
then

Field x25No is an int.

The marked pattern is not flagged in Eclipse, passes the compiler without an error, but crashes at runtime during fact insertion with:

Exception in thread "main" java.lang.UnsupportedOperationException: does not support method call isAllowed(Object object, InternalWorkingMemory workingMemoiry)
	at org.drools.rule.ReturnValueRestriction.isAllowedCachedRight(ReturnValueRestriction.java:252)
	at org.drools.rule.OrCompositeRestriction.isAllowedCachedRight(OrCompositeRestriction.java:51)
	at org.drools.rule.MultiRestrictionFieldConstraint.isAllowedCachedRight(MultiRestrictionFieldConstraint.java:115)
	at org.drools.common.DoubleBetaConstraints.isAllowedCachedRight(DoubleBetaConstraints.java:181)
	at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:172)
	at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:360)
	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:344)
	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:184)
	at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:146)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1094)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1045)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:830)
	at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:219)
	at rss.checker.engine.impl.DroolsEngine.insert(DroolsEngine.java:61)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 06:15:29 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Jul 2009 06:15:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7137) MDBs dont register
 local-jndi-name when provided in jboss.xml
In-Reply-To: <1347556772.1248932189281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <713183371.1249035329266.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved JBAS-7137.
---------------------------------

    Resolution: Rejected


The assertion isn't made on the bases of the existence of an element in the xsd.

I guess you are referring to the 'JMX Notifications' in http://www.jboss.org/community/wiki/JBossMDB of EJB 2 MDBs in AS 4.0.2. In which case we're talking about MBean names, not JNDI names.
Said construct is unsupported in EJB 3 MDBs in AS 5.

Use the forum if you want to discuss new requirements. 

> MDBs dont register local-jndi-name when provided in jboss.xml
> -------------------------------------------------------------
>
>                 Key: JBAS-7137
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7137
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: WIndows, Java 1.6 huge fat fast machine with thousands of terabytes
>            Reporter: Bill Culp
>            Assignee: Carlo de Wolf
>
> MDBs do not register a JNDI name at all even when local-jndi-name is specified in the jboss.xml and can only be looked up using jboss.j2ee:jar=foo, name=fooname, service=EJB3.
> Also start stop destroy create methods as provided for EJB beans in JMX are not provided.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 06:35:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Jul 2009 06:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1016) memory leak in GMS
	protocol
In-Reply-To: <1523793676.1248774569291.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1999913897.1249036529166.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1016:
---------------------------

    Fix Version/s: 2.6.12
                       (was: 2.6.11)


> memory leak in GMS protocol
> ---------------------------
>
>                 Key: JGRP-1016
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1016
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.7
>            Reporter: Miro Selent
>            Assignee: Bela Ban
>             Fix For: 2.6.12, 2.8
>
>
> Found in org.jgroups.protocols.pbcast.GMS in a scenario where members were killed and restarted very frequently and one member is persistently running. The memory consumption icreased very quickly until OutOfMemory.
> Our analysis with JProfiler leads to the following assumption:
> The number of org.jgroups.stack.IpAddress held by merge_ack_collector icreases every time a member was (re)started. 
> These instances were never removed because no MERGE events occured. This is completely clear since there was only one coordinator (the long running member). 
> If GMS receives no MERGE event it never cleans up the stored IpAddress instances in the merge_ack_collector.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 06:37:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Jul 2009 06:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1019) GossipRouter: loops
	at 40% CPU
Message-ID: <436763536.1249036649104.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

GossipRouter: loops at 40% CPU
------------------------------

                 Key: JGRP-1019
                 URL: https://jira.jboss.org/jira/browse/JGRP-1019
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.4.7, 2.6.12, 2.8


main() calls mainLoop() which uses a Scanner to parse the command line. When started without a valid stdin, Scanner loos at 40%. SOLUTION: remove Scanner (tested, it works)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 06:49:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Jul 2009 06:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1020) CLOUD_PING:
 investigate discovery protocol (similar to FILE_PING) on S3 etc
Message-ID: <1656400149.1249037369118.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLOUD_PING: investigate discovery protocol (similar to FILE_PING) on S3 etc
---------------------------------------------------------------------------

                 Key: JGRP-1020
                 URL: https://jira.jboss.org/jira/browse/JGRP-1020
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.x




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 07:53:29 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Fri, 31 Jul 2009 07:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-1879) EJB3 Deployment
 Issue on AS trunk
Message-ID: <1058343557.1249041209911.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

EJB3 Deployment Issue on AS trunk
---------------------------------

                 Key: EJBTHREE-1879
                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1879
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: 1.1.10
            Reporter: Richard Opalka
             Fix For: 1.1.11
         Attachments: jaxws-jbws1309-client.jar

13:44:55,242 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/opt/svn/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/default/deploy/jaxws-jbws1309.jar/ state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Error deploying jaxws-jbws1309.jar: No container configured with name 'Stateless Bean''
	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:60)
	at org.jboss.deployers.vfs.spi.deployer.AbstractSimpleVFSRealDeployer.deploy(AbstractSimpleVFSRealDeployer.java:56)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
	at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.RuntimeException: No container configured with name 'Stateless Bean''
	at org.jboss.ejb3.Ejb3AnnotationHandler.getStatelessContainer(Ejb3AnnotationHandler.java:310)
	at org.jboss.ejb3.Ejb3DescriptorHandler.getStatelessContainer(Ejb3DescriptorHandler.java:499)
	at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:206)
	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:734)
	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:685)
	at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:667)
	at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:630)
	at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:507)
	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
	... 34 more


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 07:53:30 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Fri, 31 Jul 2009 07:53:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1879) EJB3 Deployment
 Issue on AS trunk
In-Reply-To: <1058343557.1249041209911.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <440849394.1249041210054.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated EJBTHREE-1879:
-------------------------------------

    Attachment: jaxws-jbws1309-client.jar


Client archive

> EJB3 Deployment Issue on AS trunk
> ---------------------------------
>
>                 Key: EJBTHREE-1879
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1879
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.10
>            Reporter: Richard Opalka
>             Fix For: 1.1.11
>
>         Attachments: jaxws-jbws1309-client.jar
>
>
> 13:44:55,242 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/opt/svn/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/default/deploy/jaxws-jbws1309.jar/ state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Error deploying jaxws-jbws1309.jar: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:60)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractSimpleVFSRealDeployer.deploy(AbstractSimpleVFSRealDeployer.java:56)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.RuntimeException: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getStatelessContainer(Ejb3AnnotationHandler.java:310)
> 	at org.jboss.ejb3.Ejb3DescriptorHandler.getStatelessContainer(Ejb3DescriptorHandler.java:499)
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:206)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:734)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:685)
> 	at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:667)
> 	at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:630)
> 	at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:507)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
> 	... 34 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 07:55:29 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Fri, 31 Jul 2009 07:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1879) EJB3 Deployment
 Issue on AS trunk
In-Reply-To: <1058343557.1249041209911.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <495381628.1249041329186.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated EJBTHREE-1879:
-------------------------------------

    Attachment: jaxws-jbws1309.jar


Service jar.

> EJB3 Deployment Issue on AS trunk
> ---------------------------------
>
>                 Key: EJBTHREE-1879
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1879
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.10
>            Reporter: Richard Opalka
>             Fix For: 1.1.11
>
>         Attachments: jaxws-jbws1309-client.jar, jaxws-jbws1309.jar
>
>
> 13:44:55,242 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/opt/svn/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/default/deploy/jaxws-jbws1309.jar/ state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Error deploying jaxws-jbws1309.jar: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:60)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractSimpleVFSRealDeployer.deploy(AbstractSimpleVFSRealDeployer.java:56)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.RuntimeException: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getStatelessContainer(Ejb3AnnotationHandler.java:310)
> 	at org.jboss.ejb3.Ejb3DescriptorHandler.getStatelessContainer(Ejb3DescriptorHandler.java:499)
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:206)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:734)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:685)
> 	at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:667)
> 	at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:630)
> 	at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:507)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
> 	... 34 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 07:55:29 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Fri, 31 Jul 2009 07:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-1879) EJB3
 Deployment Issue on AS trunk
In-Reply-To: <1058343557.1249041209911.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <413155676.1249041329260.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/EJBTHREE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478379#action_12478379 ] 

Richard Opalka commented on EJBTHREE-1879:
------------------------------------------

To reproduce the issue just place both jar files to 
JBOSS_TRUNK_HOME/server/default/deploy directory and start AS.

Deployment of these files works fine on AS Branch_5_x

> EJB3 Deployment Issue on AS trunk
> ---------------------------------
>
>                 Key: EJBTHREE-1879
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1879
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.10
>            Reporter: Richard Opalka
>             Fix For: 1.1.11
>
>         Attachments: jaxws-jbws1309-client.jar, jaxws-jbws1309.jar
>
>
> 13:44:55,242 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/opt/svn/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/default/deploy/jaxws-jbws1309.jar/ state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Error deploying jaxws-jbws1309.jar: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:60)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractSimpleVFSRealDeployer.deploy(AbstractSimpleVFSRealDeployer.java:56)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.RuntimeException: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getStatelessContainer(Ejb3AnnotationHandler.java:310)
> 	at org.jboss.ejb3.Ejb3DescriptorHandler.getStatelessContainer(Ejb3DescriptorHandler.java:499)
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:206)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:734)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:685)
> 	at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:667)
> 	at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:630)
> 	at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:507)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
> 	... 34 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 08:01:29 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Fri, 31 Jul 2009 08:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <222264770.1249041689390.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------

    Attachment: QueueExampleLong3.java


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: QueueExample.java, QueueExampleLong.java, QueueExampleLong2.java, QueueExampleLong3.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 08:05:29 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Fri, 31 Jul 2009 08:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1822384129.1249041929320.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------

    Attachment: FullSize200_Server.log


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: FullSize200.jpeg, FullSize200_Server.log, QueueExample.java, QueueExampleLong.java, QueueExampleLong2.java, QueueExampleLong3.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 08:05:29 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Fri, 31 Jul 2009 08:05:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <781785375.1249041929467.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------

    Attachment: FullSize200.jpeg


> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: FullSize200.jpeg, FullSize200_Server.log, QueueExample.java, QueueExampleLong.java, QueueExampleLong2.java, QueueExampleLong3.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 08:25:29 2009
From: jira-events at lists.jboss.org (Martin Gysel (JIRA))
Date: Fri, 31 Jul 2009 08:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1685) jboss
 messaging / memory leak on session.rollback() operation
In-Reply-To: <2096599904.1247571869739.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1863173241.1249043129384.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Gysel updated JBMESSAGING-1685:
--------------------------------------


hi howard, thanks for your feedback. i changed the queue defs as follows:

<mbean code="org.jboss.jms.server.destination.QueueService"
      name="jboss.messaging.destination:service=Queue,name=testQueue"
      xmbean-dd="xmdesc/Queue-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends>jboss.messaging:service=PostOffice</depends>
      <attribute name="MaxDeliveryAttempts">10</attribute>
      <attribute name="FullSize">200</attribute>
      <attribute name="PageSize">100</attribute>
      <attribute name="DownCacheSize">100</attribute>
      <attribute name="SecurityConfig">
         <security>
            <role name="guest" read="true" write="true"/>
            <role name="publisher" read="true" write="true" create="false"/>
            <role name="noacc" read="false" write="false" create="false"/>
         </security>
      </attribute>
   </mbean>

the test case with 100K messages should now occupy a max of about 20MB (200 x 100K). before running the test again i changed the test program to adapt as realistic as possible to our current application logic. so the loop now takes place in the main() method and in the receiving of the messages (MaxDeliveryAttempts set to 10). there is no commit() operation anymore ( see the attached file QueueExampleLong3).
many more 'rounds' can be run with this logic and the above configuration. after about 4060 rounds the OOM in the java heap space occurs again. when running with 500K messages the OOM occurs after 817 rounds (factor 5 matches for sizes and number of rounds). these tests were done with a DLQ specified. i assume that a similar or alike behaviour can be expected with a DLQ as well.
attached you'll also find another screen shot und server log. the screen shot of the jconsole memory view shows the continous growth of memory over time.
thank you very much for your help. kind regards martin



> jboss messaging / memory leak on session.rollback() operation
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1685
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1685
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: Windows Server 2003/SP2
>            Reporter: Martin Gysel
>            Assignee: Howard Gao
>             Fix For: 1.4.0.SP3.CP09, 1.4.5.GA
>
>         Attachments: FullSize200.jpeg, FullSize200_Server.log, QueueExample.java, QueueExampleLong.java, QueueExampleLong2.java, QueueExampleLong3.java, Test100K.jpg, Test10K.jpg
>
>
> we run a transacted jms application using jboss 5.1.0.GA and jboss messaging 1.4.3.GA. if a received message could not be successfully processed, e.g. because another subsystem is not available, the application issues a rollback() operation on the session. by default it is presented again 10 times until it is discarded/removed. as the jms workload is quite high sooner or later the application server ends up in out of memory conditions in heap space.
> the case can easily be reproduced with a small test application (one program sending messages, the other one receiving). the following cases/setups have been tested and ran into this memory leak
> - close session/connection after this many rollback() operations, e.g. 100
> - close session/connection after all messages have been received (and removed)
> - clustered vs. not clustered makes no difference
> - hypersonic vs. db2 makes no difference
> - adding a DLQ makes no difference
> - DeliveryMode.NON_PERSISTENT makes no difference
> the same problem can also be seen with jboss 4.2.3.GA and jboss messaging 1.4.2.GA.
> session.commit() operations (x thousands and more) do not lead to a leak
> we do not use XA.
> thanks for your help.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 08:35:41 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Jul 2009 08:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1021) CLOUD_TCP: more
 scalable impl of TCP
Message-ID: <581113458.1249043741624.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CLOUD_TCP: more scalable impl of TCP
------------------------------------

                 Key: JGRP-1021
                 URL: https://jira.jboss.org/jira/browse/JGRP-1021
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.9


See JGroups/doc/design/CLOUD_TCP.txt for details

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 08:56:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Jul 2009 08:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1019) GossipRouter: loops
	at 40% CPU
In-Reply-To: <436763536.1249036649104.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1375154786.1249044989236.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1019:
---------------------------

    Fix Version/s:     (was: 2.8)
                       (was: 2.4.7)


fixed on 2.6.12, not needed on 2.8 as we've already removed the Scanner

> GossipRouter: loops at 40% CPU
> ------------------------------
>
>                 Key: JGRP-1019
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1019
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.6.12
>
>
> main() calls mainLoop() which uses a Scanner to parse the command line. When started without a valid stdin, Scanner loos at 40%. SOLUTION: remove Scanner (tested, it works)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 08:56:29 2009
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 31 Jul 2009 08:56:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1019) GossipRouter: loops
	at 40% CPU
In-Reply-To: <436763536.1249036649104.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1313784535.1249044989303.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JGRP-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1019.
----------------------------

    Resolution: Done


> GossipRouter: loops at 40% CPU
> ------------------------------
>
>                 Key: JGRP-1019
>                 URL: https://jira.jboss.org/jira/browse/JGRP-1019
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.6.12
>
>
> main() calls mainLoop() which uses a Scanner to parse the command line. When started without a valid stdin, Scanner loos at 40%. SOLUTION: remove Scanner (tested, it works)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 09:00:30 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Jul 2009 09:00:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1879) EJB3 Deployment
 Issue on AS trunk
In-Reply-To: <1058343557.1249041209911.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1961165696.1249045230717.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf reassigned EJBTHREE-1879:
---------------------------------------

    Assignee: Carlo de Wolf


> EJB3 Deployment Issue on AS trunk
> ---------------------------------
>
>                 Key: EJBTHREE-1879
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1879
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.10
>            Reporter: Richard Opalka
>            Assignee: Carlo de Wolf
>         Attachments: jaxws-jbws1309-client.jar, jaxws-jbws1309.jar
>
>
> 13:44:55,242 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/opt/svn/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/default/deploy/jaxws-jbws1309.jar/ state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Error deploying jaxws-jbws1309.jar: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:60)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractSimpleVFSRealDeployer.deploy(AbstractSimpleVFSRealDeployer.java:56)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.RuntimeException: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getStatelessContainer(Ejb3AnnotationHandler.java:310)
> 	at org.jboss.ejb3.Ejb3DescriptorHandler.getStatelessContainer(Ejb3DescriptorHandler.java:499)
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:206)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:734)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:685)
> 	at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:667)
> 	at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:630)
> 	at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:507)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
> 	... 34 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 09:00:30 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Jul 2009 09:00:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1879) EJB3 Deployment
 Issue on AS trunk
In-Reply-To: <1058343557.1249041209911.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1064802733.1249045230839.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf updated EJBTHREE-1879:
------------------------------------

    Fix Version/s:     (was: 1.1.11)


> EJB3 Deployment Issue on AS trunk
> ---------------------------------
>
>                 Key: EJBTHREE-1879
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1879
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.10
>            Reporter: Richard Opalka
>            Assignee: Carlo de Wolf
>         Attachments: jaxws-jbws1309-client.jar, jaxws-jbws1309.jar
>
>
> 13:44:55,242 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/opt/svn/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/default/deploy/jaxws-jbws1309.jar/ state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Error deploying jaxws-jbws1309.jar: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:60)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractSimpleVFSRealDeployer.deploy(AbstractSimpleVFSRealDeployer.java:56)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.RuntimeException: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getStatelessContainer(Ejb3AnnotationHandler.java:310)
> 	at org.jboss.ejb3.Ejb3DescriptorHandler.getStatelessContainer(Ejb3DescriptorHandler.java:499)
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:206)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:734)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:685)
> 	at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:667)
> 	at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:630)
> 	at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:507)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
> 	... 34 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 09:02:29 2009
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 31 Jul 2009 09:02:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1879) EJB3 Deployment
 Issue on AS trunk
In-Reply-To: <1058343557.1249041209911.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2016482001.1249045349346.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/EJBTHREE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved EJBTHREE-1879.
-------------------------------------

    Resolution: Done


Build issue in trunk, introduced in JBBUILD-539 rev 91803.

http://fisheye.jboss.org/browse/JBossAS/trunk/ejb3/pom.xml?r1=87828&r2=91803

> EJB3 Deployment Issue on AS trunk
> ---------------------------------
>
>                 Key: EJBTHREE-1879
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1879
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: 1.1.10
>            Reporter: Richard Opalka
>            Assignee: Carlo de Wolf
>         Attachments: jaxws-jbws1309-client.jar, jaxws-jbws1309.jar
>
>
> 13:44:55,242 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/opt/svn/jbossas/trunk/build/output/jboss-6.0.0.Alpha1/server/default/deploy/jaxws-jbws1309.jar/ state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Error deploying jaxws-jbws1309.jar: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:60)
> 	at org.jboss.deployers.vfs.spi.deployer.AbstractSimpleVFSRealDeployer.deploy(AbstractSimpleVFSRealDeployer.java:56)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.RuntimeException: No container configured with name 'Stateless Bean''
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getStatelessContainer(Ejb3AnnotationHandler.java:310)
> 	at org.jboss.ejb3.Ejb3DescriptorHandler.getStatelessContainer(Ejb3DescriptorHandler.java:499)
> 	at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:206)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:734)
> 	at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:685)
> 	at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:667)
> 	at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:630)
> 	at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:507)
> 	at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
> 	... 34 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 09:32:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 31 Jul 2009 09:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1696) Server logs
 should include client's IP in case of client crash
Message-ID: <1032475927.1249047149502.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Server logs should include client's IP in case of client crash
--------------------------------------------------------------

                 Key: JBMESSAGING-1696
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1696
             Project: JBoss Messaging
          Issue Type: Feature Request
            Reporter: Clebert Suconic
            Assignee: Tim Fox
             Fix For: 2.0.0




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 10:04:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Fri, 31 Jul 2009 10:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7130) Stack trace when
 starting up "all" configuration
In-Reply-To: <1446554410.1248826962724.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1719318638.1249049069474.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478408#action_12478408 ] 

Stan Silvert commented on JBAS-7130:
------------------------------------

Same way.  If there is a WAR without a web.xml then add one.

> Stack trace when starting up "all" configuration
> ------------------------------------------------
>
>                 Key: JBAS-7130
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7130
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF, Web (Tomcat) service
>            Reporter: David Lloyd
>            Assignee: Stan Silvert
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> I get the following stack trace when starting up in the "all" configuration:
> 19:19:07,154 INFO  [TomcatDeployment] deploy, ctxPath=/invoker
> 19:19:07,187 WARNING [config] Unable to process deployment descriptor for context '/invoker': java.lang.IllegalArgumentException: InputStream cannot be null
> 	at javax.xml.parsers.SAXParser.parse(SAXParser.java:194)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.scanForFacesServlet(ConfigureListener.java:752)
> 	at com.sun.faces.config.ConfigureListener$WebXmlProcessor.<init>(ConfigureListener.java:712)
> 	at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:165)
> 	at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:60)
> 	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
> 	at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
> 	at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:462)
> 	at org.jboss.web.deployers.WebModule.startModule(WebModule.java:116)
> 	at org.jboss.web.deployers.WebModule.start(WebModule.java:95)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:207)
> 	at $Proxy38.start(Unknown Source)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
> 	at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:653)
> 	at org.jboss.system.ServiceController.register(ServiceController.java:356)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerRegistrationLifecycleCallback.install(ServiceControllerRegistrationLifecycleCallback.java:104)
> 	at sun.reflect.GeneratedMethodAccessor239.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:443)
> 	at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
> 	at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:291)
> 	at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
> 	at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1569)
> 	at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1534)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:944)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:260)
> 	at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:102)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:829)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:432)
> 	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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 10:11:30 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 31 Jul 2009 10:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMAN-91) SerialVersionUID
 test detecting mismatch with org.jboss.managed.plugins.ManagedObjectImpl
In-Reply-To: <2047708221.1246383151330.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1400844825.1249049490038.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMAN-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBMAN-91.
--------------------------------

    Resolution: Won't Fix


Due to the following issues, there was an incompatible change in the serialized format of the MangedObjectImp, so the version was changed to 3, so that is the correct version for 2.1.1.GA on.

JBMAN-86, mark the attachments as transient
JBMAN-87, skip the serialization of the fields ANNOTATIONS


> SerialVersionUID test detecting mismatch with org.jboss.managed.plugins.ManagedObjectImpl
> -----------------------------------------------------------------------------------------
>
>                 Key: JBMAN-91
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-91
>             Project: JBoss Managed
>          Issue Type: Bug
>          Components: general
>            Reporter: Shelly McGowan
>            Assignee: Scott M Stark
>             Fix For: JBossMan.2.1.1.GA 
>
>
> Since 2.1.1.CR1 release, JBoss AS integration testsuite showing this failure when compariing serialVer UIDs to 500 and 501:
> FAIL: serialVersionUID error for org.jboss.managed.plugins.ManagedObjectImpl, 500 2, current: 3
> FAIL: serialVersionUID error for org.jboss.managed.plugins.ManagedObjectImpl, 501 2, current: 3

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 10:35:30 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Fri, 31 Jul 2009 10:35:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
Message-ID: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

EJB2 MDB managed component doesn't report correct CreateCount
-------------------------------------------------------------

                 Key: JBAS-7141
                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: ProfileService
    Affects Versions: JBossAS-5.2.0.Beta1
            Reporter: Lukas Krejci
            Assignee: Scott M Stark


The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 10:39:29 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 31 Jul 2009 10:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMAN-65) Support for JMX
	annotations
In-Reply-To: <18968897.1237194022581.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1419037737.1249051169416.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMAN-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark updated JBMAN-65:
-------------------------------

    Fix Version/s: JBoss Managed 2.2.0.GA
                       (was: JBossMan.2.0.1.CR1)


> Support for JMX annotations
> ---------------------------
>
>                 Key: JBMAN-65
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-65
>             Project: JBoss Managed
>          Issue Type: Feature Request
>          Components: managedobject
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBoss Managed 2.2.0.GA
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Feature request from JBAS-5339, Provide support for JSR-255 JMX annotations (@ManagedResource,
> @ManagedAttribute, @ManagedOperation...etc) until Java 7 is supported.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 10:39:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Fri, 31 Jul 2009 10:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
In-Reply-To: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2015704420.1249051169541.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7141:
---------------------------------

    Assignee: Jason T. Greene  (was: Scott M Stark)


Jason, is this a problem with the profile service mapping or the underlying mbean value?

> EJB2 MDB managed component doesn't report correct CreateCount
> -------------------------------------------------------------
>
>                 Key: JBAS-7141
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>
> The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 10:39:29 2009
From: jira-events at lists.jboss.org (Charles Crouch (JIRA))
Date: Fri, 31 Jul 2009 10:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
In-Reply-To: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <782727393.1249051169768.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Charles Crouch updated JBAS-7141:
---------------------------------

    Labels: embjopr1_3  (was: )


> EJB2 MDB managed component doesn't report correct CreateCount
> -------------------------------------------------------------
>
>                 Key: JBAS-7141
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>
> The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 10:45:29 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 31 Jul 2009 10:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAN-92) Reduce log level of
 the "Cannot create String name from non-Simple property" msg
Message-ID: <908984637.1249051529188.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Reduce log level of the "Cannot create String name from non-Simple property" msg
--------------------------------------------------------------------------------

                 Key: JBMAN-92
                 URL: https://jira.jboss.org/jira/browse/JBMAN-92
             Project: JBoss Managed
          Issue Type: Feature Request
    Affects Versions: JBossMan.2.1.1.CR1
            Reporter: Scott M Stark
            Assignee: Scott M Stark
             Fix For: JBossMan.2.1.1.GA , JBoss Managed 2.2.0 Beta1


Related to JBAS-6833, the log level of the msg the default ManagedObjectPopular emits when a value for a property tagged as a ManagementObjectID if the value cannot be obtained should only be a debug level msg as there is no guarantee that a value exists.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 11:23:29 2009
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 31 Jul 2009 11:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-539) Switch dependency
 resolution to use poms in dist and testsuite instead of in thirdparty.
In-Reply-To: <198920888.1248465209185.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <798537430.1249053809227.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBBUILD-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier closed JBBUILD-539.
-----------------------------

    Resolution: Done


POMs in build and testsuite directories are now used for dependency resolution.

> Switch dependency resolution to use poms in dist and testsuite instead of in thirdparty.
> ----------------------------------------------------------------------------------------
>
>                 Key: JBBUILD-539
>                 URL: https://jira.jboss.org/jira/browse/JBBUILD-539
>             Project: JBoss Build System
>          Issue Type: Sub-task
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 11:23:29 2009
From: jira-events at lists.jboss.org (steve bucknam (JIRA))
Date: Fri, 31 Jul 2009 11:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-87)
 JBossEntityResolver.loadClasspathResource causes NPE when running via JNI
Message-ID: <358401369.1249053809480.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JBossEntityResolver.loadClasspathResource causes NPE when running via JNI
-------------------------------------------------------------------------

                 Key: JBCOMMON-87
                 URL: https://jira.jboss.org/jira/browse/JBCOMMON-87
             Project: JBoss Common
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: common-core (2.x)
    Affects Versions: 2.2.13.GA
         Environment: windows xp 32-bit, MS Visual C++ 2008,  eclipse 3.4.2 with Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
            Reporter: steve bucknam


I created a C++ program the invokes a Java method via JNI.  The classpath is setup to include all required JBoss Cache 3.1.0 jars including JBoss Common.  This method instantiates JBoss Cache as follows:

	    	CacheFactory<String, String> aFactory = new DefaultCacheFactory<String, String>();
	    	Cache cache = aFactory.createCache(configFile);

This causes a NullPointerException in JBossEntityResolver.loadClasspathResource().  The code is as follows:

    ClassLoader loader = Thread.currentThread().getContextClassLoader();
    URL url = loader.getResource(resource);

The ContextClassLoader will always be null when run within JNI.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 11:29:29 2009
From: jira-events at lists.jboss.org (Lukas Krejci (JIRA))
Date: Fri, 31 Jul 2009 11:29:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
In-Reply-To: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <756233173.1249054169196.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478435#action_12478435 ] 

Lukas Krejci commented on JBAS-7141:
------------------------------------

I added a test app to easily reproduce this: http://anonsvn.jboss.org/repos/jopr/trunk/etc/jbas5-ejb2-mdb-test

Steps:

1) Checkout the above
2) Start an *unsecured* eap5 instance with default conf
3) mvn package
4) sh ./run.sh

> EJB2 MDB managed component doesn't report correct CreateCount
> -------------------------------------------------------------
>
>                 Key: JBAS-7141
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>
> The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:04:30 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 31 Jul 2009 12:04:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1697) Truncated
 files during compacting
Message-ID: <485854682.1249056270177.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Truncated files during compacting
---------------------------------

                 Key: JBMESSAGING-1697
                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1697
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 2.0.0.beta4
            Reporter: Clebert Suconic
            Assignee: Clebert Suconic
             Fix For: 2.0.0


Journal compacting could eventually keep truncated files, what would cause issues during loading or compacting.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:12:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 31 Jul 2009 12:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1697) Truncated
 files during compacting
In-Reply-To: <485854682.1249056270177.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <279713735.1249056749966.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBMESSAGING-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478448#action_12478448 ] 

Clebert Suconic commented on JBMESSAGING-1697:
----------------------------------------------

This bug will cause these exceptions during compacting:

java.lang.IllegalArgumentException
	at java.nio.Buffer.position(Buffer.java:218)
	at org.jboss.messaging.core.journal.impl.JournalImpl.readJournalFile(JournalImpl.java:514)
	at org.jboss.messaging.core.journal.impl.JournalImpl.compact(JournalImpl.java:1480)
	at org.jboss.messaging.core.journal.impl.JournalImpl$3.run(JournalImpl.java:2098)


> Truncated files during compacting
> ---------------------------------
>
>                 Key: JBMESSAGING-1697
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1697
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Journal compacting could eventually keep truncated files, what would cause issues during loading or compacting.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:14:30 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 31 Jul 2009 12:14:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1697) Truncated
 files during compacting
In-Reply-To: <485854682.1249056270177.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <225832351.1249056870073.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic closed JBMESSAGING-1697.
----------------------------------------

    Resolution: Done


> Truncated files during compacting
> ---------------------------------
>
>                 Key: JBMESSAGING-1697
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1697
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 2.0.0.beta4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>
> Journal compacting could eventually keep truncated files, what would cause issues during loading or compacting.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:23:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-150) API to invoke a XACML
 PDP using SAML2 payload in SOAP messages
Message-ID: <1971872941.1249057409294.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

API to invoke a XACML PDP using SAML2 payload in SOAP messages
--------------------------------------------------------------

                 Key: JBID-150
                 URL: https://jira.jboss.org/jira/browse/JBID-150
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.alpha5


The feature described in http://www.jboss.org/community/wiki/SAMLv2andXACMLv2Integration is a heavily sought after feature in highly secure environments. We need an api to make this XACML authorization request call across to a PDP trying to shield out the complex saml/soap message construction from the user.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:41:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-150) API to invoke a XACML
 PDP using SAML2 payload in SOAP messages
In-Reply-To: <1971872941.1249057409294.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <45931950.1249058489141.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-150.
------------------------------

    Resolution: Done


The wiki has been updated with the API details.

> API to invoke a XACML PDP using SAML2 payload in SOAP messages
> --------------------------------------------------------------
>
>                 Key: JBID-150
>                 URL: https://jira.jboss.org/jira/browse/JBID-150
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> The feature described in http://www.jboss.org/community/wiki/SAMLv2andXACMLv2Integration is a heavily sought after feature in highly secure environments. We need an api to make this XACML authorization request call across to a PDP trying to shield out the complex saml/soap message construction from the user.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:43:41 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:43:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBID-149)
 SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
In-Reply-To: <570484675.1248907889150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1363639827.1249058621142.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana reopened JBID-149:
--------------------------------



> SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
> -----------------------------------------------------------------------
>
>                 Key: JBID-149
>                 URL: https://jira.jboss.org/jira/browse/JBID-149
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:43:41 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:43:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-149)
 SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
In-Reply-To: <570484675.1248907889150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <672555092.1249058621205.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-149:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha5
                       (was: IDFED-1.0.0.beta1)


> SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
> -----------------------------------------------------------------------
>
>                 Key: JBID-149
>                 URL: https://jira.jboss.org/jira/browse/JBID-149
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:43:41 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:43:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-149)
 SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
In-Reply-To: <570484675.1248907889150.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1303178027.1249058621356.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-149.
------------------------------

    Resolution: Done


> SAML2Request/SAML2Response: getBinder methods to return the JAXB Binder
> -----------------------------------------------------------------------
>
>                 Key: JBID-149
>                 URL: https://jira.jboss.org/jira/browse/JBID-149
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:43:41 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:43:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-132) redirect binding
 computes incorrect signatures for SAML responses
In-Reply-To: <1330676091.1247682749094.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <622182627.1249058621521.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-132:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha5
                       (was: IDFED-1.0.0.beta1)


> redirect binding computes incorrect signatures for SAML responses
> -----------------------------------------------------------------
>
>                 Key: JBID-132
>                 URL: https://jira.jboss.org/jira/browse/JBID-132
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Marcel Kolsteren
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>         Attachments: JBID-132.txt
>
>
> When using the HTTP/Redirect binding with signature support, the signatures for SAMLResponse messages are incorrect. This is caused by the computeSignature method in the RedirectBindingSignatureUtil. This method is called for requests as well as for responses, but when it constructs the string that needs to be signed, it always uses "SAMLRequest":
>       sb.append("SAMLRequest=").append(urlEncodedRequest);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:47:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBID-148) DocumentUtil
 transformer output properties
In-Reply-To: <2080437295.1248907589597.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1508761422.1249058849567.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana reopened JBID-148:
--------------------------------



> DocumentUtil transformer output properties
> ------------------------------------------
>
>                 Key: JBID-148
>                 URL: https://jira.jboss.org/jira/browse/JBID-148
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> transformer.setOutputProperty(OutputKeys.INDENT, "no");

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:47:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-148) DocumentUtil
 transformer output properties
In-Reply-To: <2080437295.1248907589597.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <703904294.1249058849695.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-148.
------------------------------

    Resolution: Done


> DocumentUtil transformer output properties
> ------------------------------------------
>
>                 Key: JBID-148
>                 URL: https://jira.jboss.org/jira/browse/JBID-148
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> transformer.setOutputProperty(OutputKeys.INDENT, "no");

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:47:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-148) DocumentUtil
 transformer output properties
In-Reply-To: <2080437295.1248907589597.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <804772916.1249058849627.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-148:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha5
                       (was: IDFED-1.0.0.beta1)


> DocumentUtil transformer output properties
> ------------------------------------------
>
>                 Key: JBID-148
>                 URL: https://jira.jboss.org/jira/browse/JBID-148
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> transformer.setOutputProperty(OutputKeys.INDENT, "no");

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:47:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBID-146) JAXBUtil: Marshaller
 setProperty formatted output should be false
In-Reply-To: <697355791.1248895829220.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <708751784.1249058849764.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana reopened JBID-146:
--------------------------------



> JAXBUtil: Marshaller setProperty formatted output should be false
> -----------------------------------------------------------------
>
>                 Key: JBID-146
>                 URL: https://jira.jboss.org/jira/browse/JBID-146
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> It will add newlines etc that can invalidate signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:47:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-146) JAXBUtil: Marshaller
 setProperty formatted output should be false
In-Reply-To: <697355791.1248895829220.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <452506895.1249058849833.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-146:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha5
                       (was: IDFED-1.0.0.beta1)


> JAXBUtil: Marshaller setProperty formatted output should be false
> -----------------------------------------------------------------
>
>                 Key: JBID-146
>                 URL: https://jira.jboss.org/jira/browse/JBID-146
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> It will add newlines etc that can invalidate signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:47:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-146) JAXBUtil: Marshaller
 setProperty formatted output should be false
In-Reply-To: <697355791.1248895829220.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <672501674.1249058849926.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-146.
------------------------------

    Resolution: Done


> JAXBUtil: Marshaller setProperty formatted output should be false
> -----------------------------------------------------------------
>
>                 Key: JBID-146
>                 URL: https://jira.jboss.org/jira/browse/JBID-146
>             Project: JBoss Identity
>          Issue Type: Bug
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha4
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>
> It will add newlines etc that can invalidate signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:47:30 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:47:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBID-145) IDFedLSInputResolver
 should be made default for schema resolution
In-Reply-To: <1323610313.1248894281013.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1649761146.1249058850141.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana reopened JBID-145:
--------------------------------



> IDFedLSInputResolver should be made default for schema resolution
> -----------------------------------------------------------------
>
>                 Key: JBID-145
>                 URL: https://jira.jboss.org/jira/browse/JBID-145
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:47:30 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:47:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-145) IDFedLSInputResolver
 should be made default for schema resolution
In-Reply-To: <1323610313.1248894281013.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <615716207.1249058850236.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-145:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha5
                       (was: IDFED-1.0.0.beta1)


> IDFedLSInputResolver should be made default for schema resolution
> -----------------------------------------------------------------
>
>                 Key: JBID-145
>                 URL: https://jira.jboss.org/jira/browse/JBID-145
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:47:30 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:47:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-145) IDFedLSInputResolver
 should be made default for schema resolution
In-Reply-To: <1323610313.1248894281013.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <31583897.1249058850366.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-145.
------------------------------

    Resolution: Done


> IDFedLSInputResolver should be made default for schema resolution
> -----------------------------------------------------------------
>
>                 Key: JBID-145
>                 URL: https://jira.jboss.org/jira/browse/JBID-145
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:49:30 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:49:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-130)
 SOAPSAMLXACMLServlet:: PDP in init method
In-Reply-To: <2446024.1245174536331.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <705708849.1249058970001.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-130:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha4
                       (was: IDFED-1.0.0.beta1)


> SOAPSAMLXACMLServlet:: PDP in init method 
> ------------------------------------------
>
>                 Key: JBID-130
>                 URL: https://jira.jboss.org/jira/browse/JBID-130
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> Currently the PDP is creating for each request.  This can be moved to a shared PDP in the servlet and guarded by a lock to provide thread safety.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:49:30 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:49:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-130) SOAPSAMLXACMLServlet::
 PDP in init method
In-Reply-To: <2446024.1245174536331.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1494678642.1249058970067.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-130.
------------------------------

    Resolution: Done


> SOAPSAMLXACMLServlet:: PDP in init method 
> ------------------------------------------
>
>                 Key: JBID-130
>                 URL: https://jira.jboss.org/jira/browse/JBID-130
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> Currently the PDP is creating for each request.  This can be moved to a shared PDP in the servlet and guarded by a lock to provide thread safety.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:49:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBID-130)
 SOAPSAMLXACMLServlet:: PDP in init method
In-Reply-To: <2446024.1245174536331.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1991268147.1249058969932.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana reopened JBID-130:
--------------------------------



> SOAPSAMLXACMLServlet:: PDP in init method 
> ------------------------------------------
>
>                 Key: JBID-130
>                 URL: https://jira.jboss.org/jira/browse/JBID-130
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> Currently the PDP is creating for each request.  This can be moved to a shared PDP in the servlet and guarded by a lock to provide thread safety.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:49:30 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:49:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBID-128)
 DocumentBuilderFactory.setXIncludeAware set to true
In-Reply-To: <15329806.1244654336758.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1055877702.1249058970151.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana reopened JBID-128:
--------------------------------



> DocumentBuilderFactory.setXIncludeAware set to true
> ---------------------------------------------------
>
>                 Key: JBID-128
>                 URL: https://jira.jboss.org/jira/browse/JBID-128
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> DocumentUtil needs to be updated to setXIncludeAware to true on the DocumentBuilderFactory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:49:30 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:49:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-128)
 DocumentBuilderFactory.setXIncludeAware set to true
In-Reply-To: <15329806.1244654336758.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1656929246.1249058970306.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-128.
------------------------------

    Resolution: Done


> DocumentBuilderFactory.setXIncludeAware set to true
> ---------------------------------------------------
>
>                 Key: JBID-128
>                 URL: https://jira.jboss.org/jira/browse/JBID-128
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> DocumentUtil needs to be updated to setXIncludeAware to true on the DocumentBuilderFactory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:49:30 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:49:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-128)
 DocumentBuilderFactory.setXIncludeAware set to true
In-Reply-To: <15329806.1244654336758.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1176508302.1249058970238.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-128:
-------------------------------

    Fix Version/s: IDFED-1.0.0.alpha4
                       (was: IDFED-1.0.0.beta1)


> DocumentBuilderFactory.setXIncludeAware set to true
> ---------------------------------------------------
>
>                 Key: JBID-128
>                 URL: https://jira.jboss.org/jira/browse/JBID-128
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: IDFED-1.0.0.alpha3
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha4
>
>
> DocumentUtil needs to be updated to setXIncludeAware to true on the DocumentBuilderFactory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:49:30 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:49:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBID-84) WS-Trust: SAML Token
	Profile
In-Reply-To: <22333787.1240932058813.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1306008078.1249058970442.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana reopened JBID-84:
-------------------------------



> WS-Trust: SAML Token Profile
> ----------------------------
>
>                 Key: JBID-84
>                 URL: https://jira.jboss.org/jira/browse/JBID-84
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: 1.0.0.alpha2
>            Reporter: Anil Saldhana
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.beta1
>
>
> SOA-692 has requirements.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:51:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-84) WS-Trust: SAML Token
	Profile
In-Reply-To: <22333787.1240932058813.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23654740.1249059089241.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-84:
------------------------------

    Fix Version/s: IDFED-1.0.0.alpha5
                       (was: IDFED-1.0.0.beta1)


> WS-Trust: SAML Token Profile
> ----------------------------
>
>                 Key: JBID-84
>                 URL: https://jira.jboss.org/jira/browse/JBID-84
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: 1.0.0.alpha2
>            Reporter: Anil Saldhana
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.alpha5
>
>
> SOA-692 has requirements.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 12:51:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 12:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-84) WS-Trust: SAML Token
	Profile
In-Reply-To: <22333787.1240932058813.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <793061429.1249059089363.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-84.
-----------------------------

    Resolution: Done


> WS-Trust: SAML Token Profile
> ----------------------------
>
>                 Key: JBID-84
>                 URL: https://jira.jboss.org/jira/browse/JBID-84
>             Project: JBoss Identity
>          Issue Type: Feature Request
>          Components: Identity-Federation
>    Affects Versions: 1.0.0.alpha2
>            Reporter: Anil Saldhana
>            Assignee: Stefan Guilhen
>             Fix For: IDFED-1.0.0.alpha5
>
>
> SOA-692 has requirements.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 13:03:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 13:03:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-151) SOAPSAMLXACML API
 should handle secure PDPs
Message-ID: <555211862.1249059809185.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SOAPSAMLXACML API should handle secure PDPs
-------------------------------------------

                 Key: JBID-151
                 URL: https://jira.jboss.org/jira/browse/JBID-151
             Project: JBoss Identity
          Issue Type: Sub-task
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1


May require use of Apache HTTPClient or JBoss Netty.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 13:05:42 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 13:05:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-152) IDP should return
 attributes of caller such as email address
Message-ID: <1637862702.1249059942119.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

IDP should return attributes of caller such as email address
------------------------------------------------------------

                 Key: JBID-152
                 URL: https://jira.jboss.org/jira/browse/JBID-152
             Project: JBoss Identity
          Issue Type: Feature Request
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.beta1


The IDP should be configurable to return attributes of the subject such as email address etc that can be read from DB, LDAP etc.  This feature will require attribute providers to be plugged in.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 13:12:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 13:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-423)
 RequestAttributeFactory should have method for multi valued attributes
Message-ID: <1726825209.1249060349110.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

RequestAttributeFactory should have method for multi valued attributes
----------------------------------------------------------------------

                 Key: SECURITY-423
                 URL: https://jira.jboss.org/jira/browse/SECURITY-423
             Project: JBoss Security and Identity Management
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JBossXACML
    Affects Versions: jbossxacml_2.0.3.SP2
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: jbossxacml_2.0.4


If there are multiple attribute type values to a single attribute of a single type, then the method can take in an array of values and return the attribute.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 13:14:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 13:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-424) Schema Entity
 Resolver to resolve to local XACML schemas
Message-ID: <537850295.1249060469170.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Schema Entity Resolver to resolve to local XACML schemas
--------------------------------------------------------

                 Key: SECURITY-424
                 URL: https://jira.jboss.org/jira/browse/SECURITY-424
             Project: JBoss Security and Identity Management
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JBossXACML
    Affects Versions: JBossSecurity_2.0.3.SP2
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: jbossxacml_2.0.4


An entity resolver can be used for the JAXB layer that can resolve to local schemas.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 13:14:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 13:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-424) Schema Entity
 Resolver to resolve to local XACML schemas
In-Reply-To: <537850295.1249060469170.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1556132318.1249060469310.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated SECURITY-424:
-----------------------------------

    Affects Version/s: jbossxacml_2.0.3.SP2
                           (was: JBossSecurity_2.0.3.SP2)


> Schema Entity Resolver to resolve to local XACML schemas
> --------------------------------------------------------
>
>                 Key: SECURITY-424
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-424
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossXACML
>    Affects Versions: jbossxacml_2.0.3.SP2
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.4
>
>
> An entity resolver can be used for the JAXB layer that can resolve to local schemas.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 13:28:30 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Fri, 31 Jul 2009 13:28:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7142) EJB 2.0 deployments
 don't have unique JMX names
Message-ID: <1281974921.1249061310027.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

EJB 2.0 deployments don't have unique JMX names
-----------------------------------------------

                 Key: JBAS-7142
                 URL: https://jira.jboss.org/jira/browse/JBAS-7142
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: EAP 5 branch r91843
            Reporter: Ondrej ?i?ka
            Assignee: Jason T. Greene


When  two EARs with EJB 2.0 with the same name are (tried to be) deployed, those EJBs are in conflict in JMX namespace.

Partial stack trace bellow, relevant log lines attached.

-----------------

2009-07-31 19:17:56,499 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessiona.jar",service=EjbModule
javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessiona.jar&quot;,service=EjbModule",type=Component already registered.
	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
	at sun.reflect.GeneratedMethodAccessor75.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)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	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)
2009-07-31 19:17:56,503 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessionb.jar",service=EjbModule
javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessionb.jar&quot;,service=EjbModule",type=Component already registered.
	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
	at sun.reflect.GeneratedMethodAccessor75.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)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	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)
2009-07-31 19:17:56,541 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (ResourceContainer.invoker.nonDaemon-1) Error installing to Real: name=vfszip:/home/brq/ozizka/JoprEmbedded/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/eardeployment1.ear/ state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="sessiona.jar"
	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:118)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	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)
Caused by: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
	at org.jboss.system.ServiceController.install(ServiceController.java:273)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)
	... 44 more



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Fri Jul 31 13:30:29 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Fri, 31 Jul 2009 13:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7142) EJB 2.0 deployments
 don't have unique JMX names
In-Reply-To: <1281974921.1249061310027.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1977751685.1249061429325.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej ?i?ka updated JBAS-7142:
-------------------------------

    Attachment: EJB2_JMX_conflict-log.txt


> EJB 2.0 deployments don't have unique JMX names
> -----------------------------------------------
>
>                 Key: JBAS-7142
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7142
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: EAP 5 branch r91843
>            Reporter: Ondrej ?i?ka
>            Assignee: Jason T. Greene
>         Attachments: eardeployment.ear, EJB2_JMX_conflict-log.txt
>
>
> When  two EARs with EJB 2.0 with the same name are (tried to be) deployed, those EJBs are in conflict in JMX namespace.
> Partial stack trace bellow, relevant log lines attached.
> -----------------
> 2009-07-31 19:17:56,499 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessiona.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessiona.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,503 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessionb.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessionb.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,541 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (ResourceContainer.invoker.nonDaemon-1) Error installing to Real: name=vfszip:/home/brq/ozizka/JoprEmbedded/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/eardeployment1.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="sessiona.jar"
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:118)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> Caused by: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
> 	at org.jboss.system.ServiceController.install(ServiceController.java:273)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)
> 	... 44 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Fri Jul 31 13:30:29 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Fri, 31 Jul 2009 13:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7142) EJB 2.0 deployments
 don't have unique JMX names
In-Reply-To: <1281974921.1249061310027.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <63026864.1249061429684.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej ?i?ka updated JBAS-7142:
-------------------------------

    Attachment: eardeployment.ear


> EJB 2.0 deployments don't have unique JMX names
> -----------------------------------------------
>
>                 Key: JBAS-7142
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7142
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: EAP 5 branch r91843
>            Reporter: Ondrej ?i?ka
>            Assignee: Jason T. Greene
>         Attachments: eardeployment.ear, EJB2_JMX_conflict-log.txt
>
>
> When  two EARs with EJB 2.0 with the same name are (tried to be) deployed, those EJBs are in conflict in JMX namespace.
> Partial stack trace bellow, relevant log lines attached.
> -----------------
> 2009-07-31 19:17:56,499 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessiona.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessiona.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,503 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessionb.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessionb.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,541 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (ResourceContainer.invoker.nonDaemon-1) Error installing to Real: name=vfszip:/home/brq/ozizka/JoprEmbedded/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/eardeployment1.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="sessiona.jar"
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:118)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> Caused by: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
> 	at org.jboss.system.ServiceController.install(ServiceController.java:273)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)
> 	... 44 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Fri Jul 31 13:32:29 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Fri, 31 Jul 2009 13:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7142) EJB 2.0 deployments
 don't have unique JMX names
In-Reply-To: <1281974921.1249061310027.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <184723180.1249061549643.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej ?i?ka updated JBAS-7142:
-------------------------------

    Attachment: eardeployment1.ear


> EJB 2.0 deployments don't have unique JMX names
> -----------------------------------------------
>
>                 Key: JBAS-7142
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7142
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: EAP 5 branch r91843
>            Reporter: Ondrej ?i?ka
>            Assignee: Jason T. Greene
>         Attachments: eardeployment.ear, eardeployment1.ear, EJB2_JMX_conflict-log.txt
>
>
> When  two EARs with EJB 2.0 with the same name are (tried to be) deployed, those EJBs are in conflict in JMX namespace.
> Partial stack trace bellow, relevant log lines attached.
> -----------------
> 2009-07-31 19:17:56,499 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessiona.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessiona.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,503 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessionb.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessionb.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,541 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (ResourceContainer.invoker.nonDaemon-1) Error installing to Real: name=vfszip:/home/brq/ozizka/JoprEmbedded/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/eardeployment1.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="sessiona.jar"
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:118)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> Caused by: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
> 	at org.jboss.system.ServiceController.install(ServiceController.java:273)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)
> 	... 44 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Fri Jul 31 13:36:29 2009
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ondrej_=C5=BDi=C5=BEka_=28JIRA=29?=)
Date: Fri, 31 Jul 2009 13:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7142) EJB 2.0 deployments
 don't have unique JMX names
In-Reply-To: <1281974921.1249061310027.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <693631772.1249061789643.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej ?i?ka updated JBAS-7142:
-------------------------------

    Description: 
When  two EARs with EJB 2.0 with the same name are (tried to be) deployed, those EJBs are in conflict in JMX namespace.

Partial stack trace bellow, relevant log lines attached.

StR:

1) Deploy ejbdeployment.ear
2) Deploy ejbdeployment1.ear  (a copy of ejbdeployment.ear)
3) Now you get: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.


-----------------

2009-07-31 19:17:56,499 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessiona.jar",service=EjbModule
javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessiona.jar&quot;,service=EjbModule",type=Component already registered.
	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
	at sun.reflect.GeneratedMethodAccessor75.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)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	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)
2009-07-31 19:17:56,503 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessionb.jar",service=EjbModule
javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessionb.jar&quot;,service=EjbModule",type=Component already registered.
	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
	at sun.reflect.GeneratedMethodAccessor75.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)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	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)
2009-07-31 19:17:56,541 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (ResourceContainer.invoker.nonDaemon-1) Error installing to Real: name=vfszip:/home/brq/ozizka/JoprEmbedded/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/eardeployment1.ear/ state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="sessiona.jar"
	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:118)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	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)
Caused by: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
	at org.jboss.system.ServiceController.install(ServiceController.java:273)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)
	... 44 more



  was:
When  two EARs with EJB 2.0 with the same name are (tried to be) deployed, those EJBs are in conflict in JMX namespace.

Partial stack trace bellow, relevant log lines attached.

-----------------

2009-07-31 19:17:56,499 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessiona.jar",service=EjbModule
javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessiona.jar&quot;,service=EjbModule",type=Component already registered.
	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
	at sun.reflect.GeneratedMethodAccessor75.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)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	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)
2009-07-31 19:17:56,503 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessionb.jar",service=EjbModule
javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessionb.jar&quot;,service=EjbModule",type=Component already registered.
	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
	at sun.reflect.GeneratedMethodAccessor75.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)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	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)
2009-07-31 19:17:56,541 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (ResourceContainer.invoker.nonDaemon-1) Error installing to Real: name=vfszip:/home/brq/ozizka/JoprEmbedded/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/eardeployment1.ear/ state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="sessiona.jar"
	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:118)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
	at org.jboss.remoting.Client.invoke(Client.java:1724)
	at org.jboss.remoting.Client.invoke(Client.java:629)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	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)
Caused by: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
	at org.jboss.system.ServiceController.install(ServiceController.java:273)
	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)
	... 44 more





> EJB 2.0 deployments don't have unique JMX names
> -----------------------------------------------
>
>                 Key: JBAS-7142
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7142
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: EAP 5 branch r91843
>            Reporter: Ondrej ?i?ka
>            Assignee: Jason T. Greene
>         Attachments: eardeployment.ear, eardeployment1.ear, EJB2_JMX_conflict-log.txt
>
>
> When  two EARs with EJB 2.0 with the same name are (tried to be) deployed, those EJBs are in conflict in JMX namespace.
> Partial stack trace bellow, relevant log lines attached.
> StR:
> 1) Deploy ejbdeployment.ear
> 2) Deploy ejbdeployment1.ear  (a copy of ejbdeployment.ear)
> 3) Now you get: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
> -----------------
> 2009-07-31 19:17:56,499 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessiona.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessiona.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,503 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessionb.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessionb.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,541 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (ResourceContainer.invoker.nonDaemon-1) Error installing to Real: name=vfszip:/home/brq/ozizka/JoprEmbedded/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/eardeployment1.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="sessiona.jar"
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:118)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> Caused by: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
> 	at org.jboss.system.ServiceController.install(ServiceController.java:273)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)
> 	... 44 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Fri Jul 31 13:38:40 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 13:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-423)
 RequestAttributeFactory should have method for multi valued attributes
In-Reply-To: <1726825209.1249060349110.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <890045476.1249061920409.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed SECURITY-423.
----------------------------------

    Resolution: Done


> RequestAttributeFactory should have method for multi valued attributes
> ----------------------------------------------------------------------
>
>                 Key: SECURITY-423
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-423
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossXACML
>    Affects Versions: jbossxacml_2.0.3.SP2
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.4
>
>
> If there are multiple attribute type values to a single attribute of a single type, then the method can take in an array of values and return the attribute.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 14:12:29 2009
From: jira-events at lists.jboss.org (Scott M Stark (JIRA))
Date: Fri, 31 Jul 2009 14:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMAN-92) Reduce log level of
 the "Cannot create String name from non-Simple property" msg
In-Reply-To: <908984637.1249051529188.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <660130104.1249063949355.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMAN-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott M Stark resolved JBMAN-92.
--------------------------------

    Resolution: Done


> Reduce log level of the "Cannot create String name from non-Simple property" msg
> --------------------------------------------------------------------------------
>
>                 Key: JBMAN-92
>                 URL: https://jira.jboss.org/jira/browse/JBMAN-92
>             Project: JBoss Managed
>          Issue Type: Feature Request
>    Affects Versions: JBossMan.2.1.1.CR1
>            Reporter: Scott M Stark
>            Assignee: Scott M Stark
>             Fix For: JBossMan.2.1.1.GA , JBoss Managed 2.2.0 Beta1
>
>
> Related to JBAS-6833, the log level of the msg the default ManagedObjectPopular emits when a value for a property tagged as a ManagementObjectID if the value cannot be obtained should only be a debug level msg as there is no guarantee that a value exists.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 14:29:29 2009
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Fri, 31 Jul 2009 14:29:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7143) Upgrade AS 5.2 to
	JSF 2.0.0-Beta2
Message-ID: <1062309899.1249064969694.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade AS 5.2 to JSF 2.0.0-Beta2
---------------------------------

                 Key: JBAS-7143
                 URL: https://jira.jboss.org/jira/browse/JBAS-7143
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JSF
    Affects Versions: JBossAS-5.1.0.GA
            Reporter: Stan Silvert
            Assignee: Stan Silvert
             Fix For: JBossAS-5.2.0.Beta1


Upgrade AS 5.2 to JSF 2.0.0-Beta2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 14:34:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 14:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-7142) EJB 2.0 deployments
 don't have unique JMX names
In-Reply-To: <1281974921.1249061310027.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <381950545.1249065269297.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene closed JBAS-7142.
---------------------------------

    Resolution: Duplicate Issue


> EJB 2.0 deployments don't have unique JMX names
> -----------------------------------------------
>
>                 Key: JBAS-7142
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7142
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: EAP 5 branch r91843
>            Reporter: Ondrej ?i?ka
>            Assignee: Jason T. Greene
>         Attachments: eardeployment.ear, eardeployment1.ear, EJB2_JMX_conflict-log.txt
>
>
> When  two EARs with EJB 2.0 with the same name are (tried to be) deployed, those EJBs are in conflict in JMX namespace.
> Partial stack trace bellow, relevant log lines attached.
> StR:
> 1) Deploy ejbdeployment.ear
> 2) Deploy ejbdeployment1.ear  (a copy of ejbdeployment.ear)
> 3) Now you get: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
> -----------------
> 2009-07-31 19:17:56,499 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessiona.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessiona.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,503 WARN  [org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext] (ResourceContainer.invoker.nonDaemon-1) Unable to register deployment mbean jboss.j2ee:module="sessionb.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;sessionb.jar&quot;,service=EjbModule",type=Component already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:756)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:233)
> 	at sun.reflect.GeneratedMethodAccessor75.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)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:1034)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:725)
> 	at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:251)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
> 	at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> 2009-07-31 19:17:56,541 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (ResourceContainer.invoker.nonDaemon-1) Error installing to Real: name=vfszip:/home/brq/ozizka/JoprEmbedded/JBPAPP_5_0/build/output/jboss-5.0.0.Beta/server/default/deploy/eardeployment1.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="sessiona.jar"
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:118)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632)
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> 	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:293)
> 	at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:207)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 	at org.jboss.remoting.Client.invoke(Client.java:1724)
> 	at org.jboss.remoting.Client.invoke(Client.java:629)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304)
> 	at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:189)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:232)
> 	at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:89)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:150)
> 	at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:112)
> 	at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:417)
> 	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:239)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	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)
> Caused by: java.lang.IllegalStateException: jboss.j2ee:module="sessiona.jar",service=EjbModule is already installed.
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> 	at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
> 	at org.jboss.system.ServiceController.install(ServiceController.java:273)
> 	at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)
> 	... 44 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Fri Jul 31 14:34:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 14:34:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-6335) EjbModule is
	already installed
In-Reply-To: <28094118.1229633874615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1496777112.1249065269584.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene reopened JBAS-6335:
-----------------------------------



AFICT this was never actually fixed. The bug is in EJBDeployer, which in 4.x used to generate a random id.

> EjbModule is already installed
> ------------------------------
>
>                 Key: JBAS-6335
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6335
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows XP jdk1.6.0_11
>            Reporter: Henrik Lindell
>            Assignee: Ales Justin
>            Priority: Blocker
>             Fix For: JBossAS-5.0.1.GA, JBossAS-5.1.0.Beta1
>
>
> When deploying 2 EARs containing each an ejb 2.x jar with the same name ("my-ejbs.jar") deployment fails with this stack trace when the second  is handled by the EjbDeployer.
> The BasicMBeanRegistry tries to register them both with the name "jboss.j2ee:module=&quot;my-ejbs.jar&quot;,service=EjbModule"
> 14:33:27,796 WARN  [AbstractDeploymentContext] Unable to register deployment mbean jboss.j2ee:module="my-ejbs.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;my-ejbs.jar&quot;,service=EjbModule",type=Component already registered.
>         at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:767)
>         at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:236)
>         at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
>         at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
>         at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
>         at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:989)
>         at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:719)
>         at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:249)
>         at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
>         at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
>         at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
>         at org.jboss.Main.boot(Main.java:209)
>         at org.jboss.Main$1.run(Main.java:547)
>         at java.lang.Thread.run(Thread.java:619)
> 14:33:27,828 INFO  [TomcatDeployment] deploy, ctxPath=/abc-6-0-4, vfsUrl=my-ear-6-0-4.ear/webApp.war
> 14:33:28,046 WARN  [TomcatDeployment] Failed to setup clustering, clustering disabled. NoClassDefFoundError: org/jboss/cache/pojo/jmx/PojoCacheJmxWrapperMBean
> 14:33:28,125 INFO  [EjbModule] Deploying AbcSLS
> 14:33:28,203 INFO  [ProxyFactory] Bound EJB Home 'AbcSLS' to jndi 'xyz/abc-6-0-4/internal/ejb/session/Abc'
> 14:33:28,218 INFO  [ProxyFactory] Unbind EJB Home 'AbcSLS' from jndi 'xyz/abc-6-0-4/internal/ejb/session/Abc'
> 14:33:28,218 INFO  [EjbModule] Undeployed AbcSLS
> 14:33:28,218 INFO  [TomcatDeployment] undeploy, ctxPath=/abc-6-0-4, vfsUrl=my-ear-6-0-4.ear/webApp.war
> 14:33:31,015 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/C:/develop/server/jboss-5.0.0.GA.JDK6/server/standard/deploy/my-ear-6-0-4.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="my-ejbs.jar"
>         at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
>         at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:123)
>         at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:45)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
>         at org.jboss.Main.boot(Main.java:209)
>         at org.jboss.Main$1.run(Main.java:547)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.IllegalStateException: jboss.j2ee:module="my-ejbs.jar",service=EjbModule is already installed.
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
>         at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
>         at org.jboss.system.ServiceController.install(ServiceController.java:273)
>         at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:95)
>         ... 24 more
> 14:33:31,093 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS IN ERROR: Name -> Error
> vfsfile:/C:/develop/server/jboss-5.0.0.GA.JDK6/server/standard/deploy/my-ear-6-0-4.ear/ -> java.lang.IllegalStateException: jboss.j2ee:module="my-ejbs.jar",service=EjbModule is already installed.
> 14:33:31,109 INFO  [Http11Protocol] Starting Coyote HTTP/1.1 on http-127.0.0.1-8080
> 14:33:31,140 INFO  [AjpProtocol] Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009
> 14:33:31,140 INFO  [ServerImpl] JBoss (Microcontainer) [5.0.0.GA (build: SVNTag=JBoss_5_0_0_GA date=200812042120)] Started in 1m:40s:531ms

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 14:36:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 14:36:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-6335) EjbModule is
	already installed
In-Reply-To: <28094118.1229633874615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <394131110.1249065389362.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-6335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478492#action_12478492 ] 

Jason T. Greene commented on JBAS-6335:
---------------------------------------

Another workaround is to explicitly set the jmx name

> EjbModule is already installed
> ------------------------------
>
>                 Key: JBAS-6335
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6335
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows XP jdk1.6.0_11
>            Reporter: Henrik Lindell
>            Assignee: Ales Justin
>            Priority: Blocker
>             Fix For: JBossAS-5.0.1.GA, JBossAS-5.1.0.Beta1
>
>
> When deploying 2 EARs containing each an ejb 2.x jar with the same name ("my-ejbs.jar") deployment fails with this stack trace when the second  is handled by the EjbDeployer.
> The BasicMBeanRegistry tries to register them both with the name "jboss.j2ee:module=&quot;my-ejbs.jar&quot;,service=EjbModule"
> 14:33:27,796 WARN  [AbstractDeploymentContext] Unable to register deployment mbean jboss.j2ee:module="my-ejbs.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;my-ejbs.jar&quot;,service=EjbModule",type=Component already registered.
>         at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:767)
>         at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:236)
>         at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
>         at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
>         at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
>         at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:989)
>         at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:719)
>         at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:249)
>         at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
>         at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
>         at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
>         at org.jboss.Main.boot(Main.java:209)
>         at org.jboss.Main$1.run(Main.java:547)
>         at java.lang.Thread.run(Thread.java:619)
> 14:33:27,828 INFO  [TomcatDeployment] deploy, ctxPath=/abc-6-0-4, vfsUrl=my-ear-6-0-4.ear/webApp.war
> 14:33:28,046 WARN  [TomcatDeployment] Failed to setup clustering, clustering disabled. NoClassDefFoundError: org/jboss/cache/pojo/jmx/PojoCacheJmxWrapperMBean
> 14:33:28,125 INFO  [EjbModule] Deploying AbcSLS
> 14:33:28,203 INFO  [ProxyFactory] Bound EJB Home 'AbcSLS' to jndi 'xyz/abc-6-0-4/internal/ejb/session/Abc'
> 14:33:28,218 INFO  [ProxyFactory] Unbind EJB Home 'AbcSLS' from jndi 'xyz/abc-6-0-4/internal/ejb/session/Abc'
> 14:33:28,218 INFO  [EjbModule] Undeployed AbcSLS
> 14:33:28,218 INFO  [TomcatDeployment] undeploy, ctxPath=/abc-6-0-4, vfsUrl=my-ear-6-0-4.ear/webApp.war
> 14:33:31,015 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/C:/develop/server/jboss-5.0.0.GA.JDK6/server/standard/deploy/my-ear-6-0-4.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="my-ejbs.jar"
>         at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
>         at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:123)
>         at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:45)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
>         at org.jboss.Main.boot(Main.java:209)
>         at org.jboss.Main$1.run(Main.java:547)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.IllegalStateException: jboss.j2ee:module="my-ejbs.jar",service=EjbModule is already installed.
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
>         at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
>         at org.jboss.system.ServiceController.install(ServiceController.java:273)
>         at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:95)
>         ... 24 more
> 14:33:31,093 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS IN ERROR: Name -> Error
> vfsfile:/C:/develop/server/jboss-5.0.0.GA.JDK6/server/standard/deploy/my-ear-6-0-4.ear/ -> java.lang.IllegalStateException: jboss.j2ee:module="my-ejbs.jar",service=EjbModule is already installed.
> 14:33:31,109 INFO  [Http11Protocol] Starting Coyote HTTP/1.1 on http-127.0.0.1-8080
> 14:33:31,140 INFO  [AjpProtocol] Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009
> 14:33:31,140 INFO  [ServerImpl] JBoss (Microcontainer) [5.0.0.GA (build: SVNTag=JBoss_5_0_0_GA date=200812042120)] Started in 1m:40s:531ms

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 14:38:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 14:38:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-6335) EjbModule is
	already installed
In-Reply-To: <28094118.1229633874615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <553662675.1249065509516.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-6335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene reassigned JBAS-6335:
-------------------------------------

    Assignee: Jason T. Greene  (was: Ales Justin)


> EjbModule is already installed
> ------------------------------
>
>                 Key: JBAS-6335
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6335
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers
>    Affects Versions: JBossAS-5.0.0.GA
>         Environment: Windows XP jdk1.6.0_11
>            Reporter: Henrik Lindell
>            Assignee: Jason T. Greene
>            Priority: Blocker
>             Fix For: JBossAS-5.0.1.GA, JBossAS-5.1.0.Beta1
>
>
> When deploying 2 EARs containing each an ejb 2.x jar with the same name ("my-ejbs.jar") deployment fails with this stack trace when the second  is handled by the EjbDeployer.
> The BasicMBeanRegistry tries to register them both with the name "jboss.j2ee:module=&quot;my-ejbs.jar&quot;,service=EjbModule"
> 14:33:27,796 WARN  [AbstractDeploymentContext] Unable to register deployment mbean jboss.j2ee:module="my-ejbs.jar",service=EjbModule
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module=&quot;my-ejbs.jar&quot;,service=EjbModule",type=Component already registered.
>         at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:767)
>         at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:236)
>         at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
>         at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426)
>         at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
>         at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:989)
>         at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:719)
>         at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:249)
>         at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62)
>         at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150)
>         at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
>         at org.jboss.Main.boot(Main.java:209)
>         at org.jboss.Main$1.run(Main.java:547)
>         at java.lang.Thread.run(Thread.java:619)
> 14:33:27,828 INFO  [TomcatDeployment] deploy, ctxPath=/abc-6-0-4, vfsUrl=my-ear-6-0-4.ear/webApp.war
> 14:33:28,046 WARN  [TomcatDeployment] Failed to setup clustering, clustering disabled. NoClassDefFoundError: org/jboss/cache/pojo/jmx/PojoCacheJmxWrapperMBean
> 14:33:28,125 INFO  [EjbModule] Deploying AbcSLS
> 14:33:28,203 INFO  [ProxyFactory] Bound EJB Home 'AbcSLS' to jndi 'xyz/abc-6-0-4/internal/ejb/session/Abc'
> 14:33:28,218 INFO  [ProxyFactory] Unbind EJB Home 'AbcSLS' from jndi 'xyz/abc-6-0-4/internal/ejb/session/Abc'
> 14:33:28,218 INFO  [EjbModule] Undeployed AbcSLS
> 14:33:28,218 INFO  [TomcatDeployment] undeploy, ctxPath=/abc-6-0-4, vfsUrl=my-ear-6-0-4.ear/webApp.war
> 14:33:31,015 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/C:/develop/server/jboss-5.0.0.GA.JDK6/server/standard/deploy/my-ear-6-0-4.ear/ state=PreReal mode=Manual requiredState=Real
> org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="my-ejbs.jar"
>         at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
>         at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:123)
>         at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:45)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
>         at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
>         at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
>         at org.jboss.Main.boot(Main.java:209)
>         at org.jboss.Main$1.run(Main.java:547)
>         at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.IllegalStateException: jboss.j2ee:module="my-ejbs.jar",service=EjbModule is already installed.
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
>         at org.jboss.system.ServiceController.doInstall(ServiceController.java:670)
>         at org.jboss.system.ServiceController.install(ServiceController.java:273)
>         at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:95)
>         ... 24 more
> 14:33:31,093 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> *** CONTEXTS IN ERROR: Name -> Error
> vfsfile:/C:/develop/server/jboss-5.0.0.GA.JDK6/server/standard/deploy/my-ear-6-0-4.ear/ -> java.lang.IllegalStateException: jboss.j2ee:module="my-ejbs.jar",service=EjbModule is already installed.
> 14:33:31,109 INFO  [Http11Protocol] Starting Coyote HTTP/1.1 on http-127.0.0.1-8080
> 14:33:31,140 INFO  [AjpProtocol] Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009
> 14:33:31,140 INFO  [ServerImpl] JBoss (Microcontainer) [5.0.0.GA (build: SVNTag=JBoss_5_0_0_GA date=200812042120)] Started in 1m:40s:531ms

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 14:48:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 14:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-425) Ability to
 disable JBossXACML Schema Validation
In-Reply-To: <1554546966.1249066109209.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <971236866.1249066109306.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated SECURITY-425:
-----------------------------------

    Component/s: JBossXACML


> Ability to disable JBossXACML Schema Validation
> -----------------------------------------------
>
>                 Key: SECURITY-425
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-425
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossXACML
>    Affects Versions: jbossxacml_2.0.3.SP2
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.4
>
>
> The *absence* of system property "org.jboss.security.xacml.schema.validation" will always create a validating unmarshaller.
> If you do not want schema validation, then "org.jboss.security.xacml.schema.validation=false"  as system prop.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 14:48:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 14:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-425) Ability to
 disable JBossXACML Schema Validation
Message-ID: <1554546966.1249066109209.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Ability to disable JBossXACML Schema Validation
-----------------------------------------------

                 Key: SECURITY-425
                 URL: https://jira.jboss.org/jira/browse/SECURITY-425
             Project: JBoss Security and Identity Management
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: jbossxacml_2.0.3.SP2
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: jbossxacml_2.0.4


The *absence* of system property "org.jboss.security.xacml.schema.validation" will always create a validating unmarshaller.

If you do not want schema validation, then "org.jboss.security.xacml.schema.validation=false"  as system prop.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 14:48:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 14:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-425) Ability to disable
 JBossXACML Schema Validation
In-Reply-To: <1554546966.1249066109209.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <536010300.1249066109370.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed SECURITY-425.
----------------------------------

    Resolution: Done


> Ability to disable JBossXACML Schema Validation
> -----------------------------------------------
>
>                 Key: SECURITY-425
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-425
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossXACML
>    Affects Versions: jbossxacml_2.0.3.SP2
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.4
>
>
> The *absence* of system property "org.jboss.security.xacml.schema.validation" will always create a validating unmarshaller.
> If you do not want schema validation, then "org.jboss.security.xacml.schema.validation=false"  as system prop.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 14:50:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 14:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-424) Schema Entity
 Resolver to resolve to local XACML schemas
In-Reply-To: <537850295.1249060469170.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <94683937.1249066229122.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/SECURITY-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed SECURITY-424.
----------------------------------

    Resolution: Done


> Schema Entity Resolver to resolve to local XACML schemas
> --------------------------------------------------------
>
>                 Key: SECURITY-424
>                 URL: https://jira.jboss.org/jira/browse/SECURITY-424
>             Project: JBoss Security and Identity Management
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JBossXACML
>    Affects Versions: jbossxacml_2.0.3.SP2
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: jbossxacml_2.0.4
>
>
> An entity resolver can be used for the JAXB layer that can resolve to local schemas.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 15:01:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 15:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
In-Reply-To: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1447409076.1249066889433.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478495#action_12478495 ] 

Jason T. Greene commented on JBAS-7141:
---------------------------------------

CreateCount represents the number of application calls to obtaining the home instance of the bean. MDBs do not have a home instance, so the value is 0, this is the way it was on 4 as well. This is different than than the pool stats, which tell you how many instances are in use.

> EJB2 MDB managed component doesn't report correct CreateCount
> -------------------------------------------------------------
>
>                 Key: JBAS-7141
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>
> The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 15:01:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 15:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
In-Reply-To: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1671700022.1249066889576.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene resolved JBAS-7141.
-----------------------------------

    Resolution: Rejected


> EJB2 MDB managed component doesn't report correct CreateCount
> -------------------------------------------------------------
>
>                 Key: JBAS-7141
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>
> The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 15:08:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 15:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7144) JAXR Problems with
 deleted associations
Message-ID: <1089846584.1249067309116.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JAXR Problems with deleted associations
---------------------------------------

                 Key: JBAS-7144
                 URL: https://jira.jboss.org/jira/browse/JBAS-7144
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JAXR service, Test Suite
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: JBossAS-5.2.0.Beta1




==============
tests-scout-jaxr:
    [mkdir] Created dir: /home/anil/Branch_5_x/testsuite/output/log
    [junit] Running org.jboss.test.jaxr.scout.JaxrBaseTestCase     
    [junit] Running org.jboss.test.jaxr.scout.JaxrBaseTestCase     
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.685 sec
    [junit] Running org.jboss.test.jaxr.scout.basic.JaxrJNDIConnectionTestCase
    [junit] Running org.jboss.test.jaxr.scout.basic.JaxrJNDIConnectionTestCase
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.354 sec     
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase
    [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 4.051 sec          
    [junit] Test org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase FAILED
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteOrganizationTestCase   
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteOrganizationTestCase   
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.898 sec              
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveOrganizationTestCase     
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveOrganizationTestCase     
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.687 sec              
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveServiceBindingTestCase   
    [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveServiceBindingTestCase   
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.705 sec              
    [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase
    [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase
    [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 2.193 sec                
    [junit] Test org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase FAILED
    [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrConfimAssociationTestCase
    [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrConfimAssociationTestCase
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.265 sec                    
    [junit] Running org.jboss.test.jaxr.scout.query.JaxrBusinessQueryTestCase                
    [junit] Running org.jboss.test.jaxr.scout.query.JaxrBusinessQueryTestCase                
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.187 sec                    
    [junit] Running org.jboss.test.jaxr.scout.query.infomodel.JaxrFindAssociationsTestCase   
    [junit] Running org.jboss.test.jaxr.scout.query.infomodel.JaxrFindAssociationsTestCase   
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.505 sec    
==================================

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 15:10:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 15:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-153) Release JBossIdentity
 1.0.0.alpha consolidated stack
Message-ID: <1991426233.1249067429212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Release JBossIdentity 1.0.0.alpha consolidated stack
----------------------------------------------------

                 Key: JBID-153
                 URL: https://jira.jboss.org/jira/browse/JBID-153
             Project: JBoss Identity
          Issue Type: Release
          Components: Community-Build
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 15:10:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 15:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBID-153) Release JBossIdentity
 1.0.0.alpha5 consolidated stack
In-Reply-To: <1991426233.1249067429212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <251886134.1249067429369.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana updated JBID-153:
-------------------------------

          Summary: Release JBossIdentity 1.0.0.alpha5 consolidated stack  (was: Release JBossIdentity 1.0.0.alpha consolidated stack)
    Fix Version/s: IDENTITY-1.0.0.alpha5


> Release JBossIdentity 1.0.0.alpha5 consolidated stack
> -----------------------------------------------------
>
>                 Key: JBID-153
>                 URL: https://jira.jboss.org/jira/browse/JBID-153
>             Project: JBoss Identity
>          Issue Type: Release
>          Components: Community-Build
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDENTITY-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 15:10:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 15:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7144) JAXR Problems with
 deleted associations
In-Reply-To: <1089846584.1249067309116.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <780691984.1249067429430.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene updated JBAS-7144:
----------------------------------

        Parent:     (was: JBAS-7128)
    Issue Type: Bug  (was: Sub-task)


> JAXR Problems with deleted associations
> ---------------------------------------
>
>                 Key: JBAS-7144
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7144
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: EAP 5.0.0.CR3
>
>
> ==============
> tests-scout-jaxr:
>     [mkdir] Created dir: /home/anil/Branch_5_x/testsuite/output/log
>     [junit] Running org.jboss.test.jaxr.scout.JaxrBaseTestCase     
>     [junit] Running org.jboss.test.jaxr.scout.JaxrBaseTestCase     
>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.685 sec
>     [junit] Running org.jboss.test.jaxr.scout.basic.JaxrJNDIConnectionTestCase
>     [junit] Running org.jboss.test.jaxr.scout.basic.JaxrJNDIConnectionTestCase
>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.354 sec     
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase
>     [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 4.051 sec          
>     [junit] Test org.jboss.test.jaxr.scout.publish.JaxrDeleteAssociationTestCase FAILED
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteOrganizationTestCase   
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrDeleteOrganizationTestCase   
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.898 sec              
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveOrganizationTestCase     
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveOrganizationTestCase     
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.687 sec              
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveServiceBindingTestCase   
>     [junit] Running org.jboss.test.jaxr.scout.publish.JaxrSaveServiceBindingTestCase   
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.705 sec              
>     [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase
>     [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase
>     [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 2.193 sec                
>     [junit] Test org.jboss.test.jaxr.scout.publish.infomodel.JaxrClassficationTestCase FAILED
>     [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrConfimAssociationTestCase
>     [junit] Running org.jboss.test.jaxr.scout.publish.infomodel.JaxrConfimAssociationTestCase
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.265 sec                    
>     [junit] Running org.jboss.test.jaxr.scout.query.JaxrBusinessQueryTestCase                
>     [junit] Running org.jboss.test.jaxr.scout.query.JaxrBusinessQueryTestCase                
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.187 sec                    
>     [junit] Running org.jboss.test.jaxr.scout.query.infomodel.JaxrFindAssociationsTestCase   
>     [junit] Running org.jboss.test.jaxr.scout.query.infomodel.JaxrFindAssociationsTestCase   
>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.505 sec    
> ==================================

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 15:10:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 15:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-154) Release JBoss
 Identity Federation Stack 1.0.0.alpha5
Message-ID: <226344186.1249067429464.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Release JBoss Identity Federation Stack 1.0.0.alpha5
----------------------------------------------------

                 Key: JBID-154
                 URL: https://jira.jboss.org/jira/browse/JBID-154
             Project: JBoss Identity
          Issue Type: Sub-task
          Components: Identity-Federation
            Reporter: Anil Saldhana
            Assignee: Anil Saldhana
             Fix For: IDFED-1.0.0.alpha5




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 15:12:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 15:12:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-154) Release JBoss Identity
 Federation Stack 1.0.0.alpha5
In-Reply-To: <226344186.1249067429464.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <915324633.1249067549164.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-154.
------------------------------

    Resolution: Done


> Release JBoss Identity Federation Stack 1.0.0.alpha5
> ----------------------------------------------------
>
>                 Key: JBID-154
>                 URL: https://jira.jboss.org/jira/browse/JBID-154
>             Project: JBoss Identity
>          Issue Type: Sub-task
>          Components: Identity-Federation
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDFED-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 15:32:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 15:32:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBID-153) Release JBossIdentity
 1.0.0.alpha5 consolidated stack
In-Reply-To: <1991426233.1249067429212.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <249967620.1249068749146.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBID-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana closed JBID-153.
------------------------------

    Resolution: Done


> Release JBossIdentity 1.0.0.alpha5 consolidated stack
> -----------------------------------------------------
>
>                 Key: JBID-153
>                 URL: https://jira.jboss.org/jira/browse/JBID-153
>             Project: JBoss Identity
>          Issue Type: Release
>          Components: Community-Build
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: IDENTITY-1.0.0.alpha5
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 15:47:29 2009
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 31 Jul 2009 15:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBID-155) Consolidated Build:
 Create IDM Dependency pack
Message-ID: <1255484741.1249069649089.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Consolidated Build:  Create IDM Dependency pack
-----------------------------------------------

                 Key: JBID-155
                 URL: https://jira.jboss.org/jira/browse/JBID-155
             Project: JBoss Identity
          Issue Type: Task
          Components: Community-Build
            Reporter: Anil Saldhana
            Assignee: Jeff Yu


Jeff, we need to create a zip of IDM dependency pack just the way we do for OpenID.

Please take a look at how we do it for openid in:
https://svn.jboss.org/repos/jbossidentity/consolidated-build/trunk/

Just create a module such as jboss-identity-idm  and have the assembly plugin build up the zip.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 15:58:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 31 Jul 2009 15:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
In-Reply-To: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <304272728.1249070309275.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478505#action_12478505 ] 

Ian Springer commented on JBAS-7141:
------------------------------------

Then I don't think it makes sense for the PS or JMX to expose the CreateCount metric at all for MDBs. Is RemoveCount also not applicable to MDBs? I notice for EJB3, createCount and removeCount are not exposed for MDBs.


> EJB2 MDB managed component doesn't report correct CreateCount
> -------------------------------------------------------------
>
>                 Key: JBAS-7141
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>
> The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 15:58:29 2009
From: jira-events at lists.jboss.org (Ian Springer (JIRA))
Date: Fri, 31 Jul 2009 15:58:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
In-Reply-To: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <116325659.1249070309382.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Springer reopened JBAS-7141:
--------------------------------



> EJB2 MDB managed component doesn't report correct CreateCount
> -------------------------------------------------------------
>
>                 Key: JBAS-7141
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>
> The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 16:47:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 16:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
In-Reply-To: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1864343017.1249073249437.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478509#action_12478509 ] 

Jason T. Greene commented on JBAS-7141:
---------------------------------------

Right same thing, remove translates to the remove() call on the home interface. 

> EJB2 MDB managed component doesn't report correct CreateCount
> -------------------------------------------------------------
>
>                 Key: JBAS-7141
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>
> The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 16:49:29 2009
From: jira-events at lists.jboss.org (Kit Chan (JIRA))
Date: Fri, 31 Jul 2009 16:49:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2201) Rule got
 executed even does not satisfy LHS after firing an external event in Flow
In-Reply-To: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1412119706.1249073369173.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478510#action_12478510 ] 

Kit Chan commented on JBRULES-2201:
-----------------------------------

I don't have a standalone sample right now, but what I figured out is when a RuleFlowGroup node triggers an external event (from a rule in a drl file), and that event will lead to an End node that ends the main process. Then with the next run of the process (by inserting another fact), what happened is the RuleFlowGroup node that triggered the external event in the last run is trying to execute again with the previous object, which the object is removed from the working memory already, so it ends up with a Null Pointer Exception. I called the dispose method at the end of every run, but seems like it doesn't dispose everything the way it supposed to.

> Rule got executed even does not satisfy LHS after firing an external event in Flow
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2201
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert), drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP SP3, Eclipse 3.4.2
>            Reporter: Kit Chan
>            Assignee: Kris Verlaenen
>            Priority: Critical
>
> I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 16:51:29 2009
From: jira-events at lists.jboss.org (Jason T. Greene (JIRA))
Date: Fri, 31 Jul 2009 16:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7141) EJB2 MDB managed
 component doesn't report correct CreateCount
In-Reply-To: <311450584.1249050930512.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2123931538.1249073489305.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason T. Greene resolved JBAS-7141.
-----------------------------------

    Resolution: Rejected


> EJB2 MDB managed component doesn't report correct CreateCount
> -------------------------------------------------------------
>
>                 Key: JBAS-7141
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7141
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ProfileService
>    Affects Versions: JBossAS-5.2.0.Beta1
>            Reporter: Lukas Krejci
>            Assignee: Jason T. Greene
>
> The @ManagedComponent for EJB2 message driven beans contains a "CreateCount" property. This property returns 0 even in cases where a number of messages has been delivered to the bean (and MessageCount property is > 0).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 17:01:29 2009
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 31 Jul 2009 17:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1427) Journal
	Cleanup
In-Reply-To: <6551971.1222785211162.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1015445403.1249074089226.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBMESSAGING-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1427:
-----------------------------------------

    Attachment: diff.patch


The attached patch has a written test showing compacting is needed. The first file will have 500 messages. Compacting will happen frequently because of the messages on the first message.

> Journal Cleanup
> ---------------
>
>                 Key: JBMESSAGING-1427
>                 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1427
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0 Alpha
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 2.0.0
>
>         Attachments: diff.patch
>
>
> If a destination is lazy, not consuming messages for a long time, the journal will grow until those messages are consumed.
> This would be a problem with DLQs or messages taking days before they are consumed.
> Since we inform the TransactionSummary on commits, we could change the journal to support multiple current-files based on configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 17:31:29 2009
From: jira-events at lists.jboss.org (Kit Chan (JIRA))
Date: Fri, 31 Jul 2009 17:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2201) Rule got executed
 even does not satisfy LHS after firing an external event in Flow
In-Reply-To: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1199689479.1249075889228.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kit Chan updated JBRULES-2201:
------------------------------

    Attachment: DroolsTest.java


Test file

> Rule got executed even does not satisfy LHS after firing an external event in Flow
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2201
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert), drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP SP3, Eclipse 3.4.2
>            Reporter: Kit Chan
>            Assignee: Kris Verlaenen
>            Priority: Critical
>         Attachments: DroolsTest.java, SampleObject.java
>
>
> I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 17:31:29 2009
From: jira-events at lists.jboss.org (Kit Chan (JIRA))
Date: Fri, 31 Jul 2009 17:31:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2201) Rule got executed
 even does not satisfy LHS after firing an external event in Flow
In-Reply-To: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1294089372.1249075889321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kit Chan updated JBRULES-2201:
------------------------------

    Attachment: SampleObject.java


sample object

> Rule got executed even does not satisfy LHS after firing an external event in Flow
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2201
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert), drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP SP3, Eclipse 3.4.2
>            Reporter: Kit Chan
>            Assignee: Kris Verlaenen
>            Priority: Critical
>         Attachments: DroolsTest.java, SampleObject.java
>
>
> I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 17:33:29 2009
From: jira-events at lists.jboss.org (Kit Chan (JIRA))
Date: Fri, 31 Jul 2009 17:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2201) Rule got executed
 even does not satisfy LHS after firing an external event in Flow
In-Reply-To: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <922086545.1249076009236.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kit Chan updated JBRULES-2201:
------------------------------

    Attachment: ruleflow.rf


> Rule got executed even does not satisfy LHS after firing an external event in Flow
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2201
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert), drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP SP3, Eclipse 3.4.2
>            Reporter: Kit Chan
>            Assignee: Kris Verlaenen
>            Priority: Critical
>         Attachments: DroolsTest.java, ruleflow.rf, Sample.drl, SampleObject.java
>
>
> I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 17:33:29 2009
From: jira-events at lists.jboss.org (Kit Chan (JIRA))
Date: Fri, 31 Jul 2009 17:33:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2201) Rule got executed
 even does not satisfy LHS after firing an external event in Flow
In-Reply-To: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1643873681.1249076009320.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBRULES-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kit Chan updated JBRULES-2201:
------------------------------

    Attachment: Sample.drl


> Rule got executed even does not satisfy LHS after firing an external event in Flow
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2201
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert), drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP SP3, Eclipse 3.4.2
>            Reporter: Kit Chan
>            Assignee: Kris Verlaenen
>            Priority: Critical
>         Attachments: DroolsTest.java, ruleflow.rf, Sample.drl, SampleObject.java
>
>
> I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 17:35:29 2009
From: jira-events at lists.jboss.org (Kit Chan (JIRA))
Date: Fri, 31 Jul 2009 17:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2201) Rule got
 executed even does not satisfy LHS after firing an external event in Flow
In-Reply-To: <140185444.1247084931428.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1530262728.1249076129568.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBRULES-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478518#action_12478518 ] 

Kit Chan commented on JBRULES-2201:
-----------------------------------

I have attached a sample standalone (drl, rf, test, and object files) that need to run this sample, it will reproduce the error I mentioned, the rule basically just check the value of the object, and print out the object, sometimes it will print out Null, which it shouldn't happen, because if it is null, it won't match the condition in the "when" part and never activate the rule.

> Rule got executed even does not satisfy LHS after firing an external event in Flow
> ----------------------------------------------------------------------------------
>
>                 Key: JBRULES-2201
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2201
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert), drools-core (flow)
>    Affects Versions: 5.0.1.FINAL
>         Environment: Windows XP SP3, Eclipse 3.4.2
>            Reporter: Kit Chan
>            Assignee: Kris Verlaenen
>            Priority: Critical
>         Attachments: DroolsTest.java, ruleflow.rf, Sample.drl, SampleObject.java
>
>
> I am using Flow to create the workflow of the process and the rules are defined in a DRL file.  I have a rule that will trigger an external event defined in the Flow.  So the scenario is I will insert one fact in the Knowledge Session and start the process, once the process is finished, it will insert anoother fact and start another process, keep repeating this procedures for numbers of time.  The problem is once an external event got triggered once, it will cause the rule that trigger the external event everytime even the condition that specified in the LHS of the rule doesn't match.  And the fact is NULL in those cases, I checked the activation plan, the rule is not activated but still got executed somehow.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 18:53:29 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Fri, 31 Jul 2009 18:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-7145) New logging
 framework breakes JBossWS
Message-ID: <1063164047.1249080809178.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

New logging framework breakes JBossWS
-------------------------------------

                 Key: JBAS-7145
                 URL: https://jira.jboss.org/jira/browse/JBAS-7145
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Richard Opalka
            Assignee: David Lloyd
             Fix For: JBossAS-6.0.0.Alpha1


We're using thirdparty components (to be concrete e.g. Apache WS-Policy)  that require commons-logging artifact that have been removed from AS trunk :(

Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
	at org.apache.ws.policy.util.Loader.<clinit>(Loader.java:32)
	at org.apache.ws.policy.util.PolicyFactory.getPolicyReader(PolicyFactory.java:56)
	at org.jboss.ws.extensions.policy.metadata.PolicyMetaDataBuilder.processPolicyExtensions(PolicyMetaDataBuilder.java:155)
	at org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.buildMetaData(JAXWSClientMetaDataBuilder.java:92)
	at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.<init>(ServiceDelegateImpl.java:138)
	at org.jboss.ws.core.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:63)
	at javax.xml.ws.Service.<init>(Service.java:79)
	at javax.xml.ws.Service.create(Service.java:96)
	at org.jboss.test.ws.jaxws.jbws1666.TestClient.testPortAccess(TestClient.java:38)
	at org.jboss.test.ws.jaxws.jbws1666.TestClient.main(TestClient.java:48)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 18:55:29 2009
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Fri, 31 Jul 2009 18:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-7145) New logging
 framework breakes JBossWS
In-Reply-To: <1063164047.1249080809178.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2111034953.1249080929195.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


     [ https://jira.jboss.org/jira/browse/JBAS-7145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated JBAS-7145:
---------------------------------

          Component/s: Logging
    Affects Version/s: JBossAS-6.0.0.Alpha1


> New logging framework breakes JBossWS
> -------------------------------------
>
>                 Key: JBAS-7145
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7145
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-6.0.0.Alpha1
>            Reporter: Richard Opalka
>            Assignee: David Lloyd
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> We're using thirdparty components (to be concrete e.g. Apache WS-Policy)  that require commons-logging artifact that have been removed from AS trunk :(
> Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
> 	at org.apache.ws.policy.util.Loader.<clinit>(Loader.java:32)
> 	at org.apache.ws.policy.util.PolicyFactory.getPolicyReader(PolicyFactory.java:56)
> 	at org.jboss.ws.extensions.policy.metadata.PolicyMetaDataBuilder.processPolicyExtensions(PolicyMetaDataBuilder.java:155)
> 	at org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.buildMetaData(JAXWSClientMetaDataBuilder.java:92)
> 	at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.<init>(ServiceDelegateImpl.java:138)
> 	at org.jboss.ws.core.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:63)
> 	at javax.xml.ws.Service.<init>(Service.java:79)
> 	at javax.xml.ws.Service.create(Service.java:96)
> 	at org.jboss.test.ws.jaxws.jbws1666.TestClient.testPortAccess(TestClient.java:38)
> 	at org.jboss.test.ws.jaxws.jbws1666.TestClient.main(TestClient.java:48)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 19:14:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 31 Jul 2009 19:14:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7145) New logging
 framework breakes JBossWS
In-Reply-To: <1063164047.1249080809178.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <453589010.1249082069186.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478523#action_12478523 ] 

David Lloyd commented on JBAS-7145:
-----------------------------------

This class should be present in common/lib/jcl-over-slf4j.jar - I don't know why your deployment isn't seeing it unless maybe you've got some isolated classloading thing going on?

> New logging framework breakes JBossWS
> -------------------------------------
>
>                 Key: JBAS-7145
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7145
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-6.0.0.Alpha1
>            Reporter: Richard Opalka
>            Assignee: David Lloyd
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> We're using thirdparty components (to be concrete e.g. Apache WS-Policy)  that require commons-logging artifact that have been removed from AS trunk :(
> Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
> 	at org.apache.ws.policy.util.Loader.<clinit>(Loader.java:32)
> 	at org.apache.ws.policy.util.PolicyFactory.getPolicyReader(PolicyFactory.java:56)
> 	at org.jboss.ws.extensions.policy.metadata.PolicyMetaDataBuilder.processPolicyExtensions(PolicyMetaDataBuilder.java:155)
> 	at org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.buildMetaData(JAXWSClientMetaDataBuilder.java:92)
> 	at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.<init>(ServiceDelegateImpl.java:138)
> 	at org.jboss.ws.core.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:63)
> 	at javax.xml.ws.Service.<init>(Service.java:79)
> 	at javax.xml.ws.Service.create(Service.java:96)
> 	at org.jboss.test.ws.jaxws.jbws1666.TestClient.testPortAccess(TestClient.java:38)
> 	at org.jboss.test.ws.jaxws.jbws1666.TestClient.main(TestClient.java:48)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Jul 31 20:08:29 2009
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 31 Jul 2009 20:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7145) New logging
 framework breakes JBossWS
In-Reply-To: <1063164047.1249080809178.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1130946369.1249085309321.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


    [ https://jira.jboss.org/jira/browse/JBAS-7145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478524#action_12478524 ] 

David Lloyd commented on JBAS-7145:
-----------------------------------

Where exactly is this exception coming from?  If this is not something that runs inside the AS, I'm inclined to close this as "Not a bug".

> New logging framework breakes JBossWS
> -------------------------------------
>
>                 Key: JBAS-7145
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7145
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: JBossAS-6.0.0.Alpha1
>            Reporter: Richard Opalka
>            Assignee: David Lloyd
>             Fix For: JBossAS-6.0.0.Alpha1
>
>
> We're using thirdparty components (to be concrete e.g. Apache WS-Policy)  that require commons-logging artifact that have been removed from AS trunk :(
> Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
> 	at org.apache.ws.policy.util.Loader.<clinit>(Loader.java:32)
> 	at org.apache.ws.policy.util.PolicyFactory.getPolicyReader(PolicyFactory.java:56)
> 	at org.jboss.ws.extensions.policy.metadata.PolicyMetaDataBuilder.processPolicyExtensions(PolicyMetaDataBuilder.java:155)
> 	at org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.buildMetaData(JAXWSClientMetaDataBuilder.java:92)
> 	at org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.<init>(ServiceDelegateImpl.java:138)
> 	at org.jboss.ws.core.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:63)
> 	at javax.xml.ws.Service.<init>(Service.java:79)
> 	at javax.xml.ws.Service.create(Service.java:96)
> 	at org.jboss.test.ws.jaxws.jbws1666.TestClient.testPortAccess(TestClient.java:38)
> 	at org.jboss.test.ws.jaxws.jbws1666.TestClient.main(TestClient.java:48)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


